Blush

(function( ) {
})();

Вот эта конструкция называется "анонимная самовызываемая функция".

То есть, тут два действия:
Объявление анонимной функции

function( ) {
}

и сразу ее вызов
()()
Первые скобки это синтаксический приём для вызова анонимной функции. Есть и другие методы. Например
+function(){}()
Вторые скобки - это собственно вызов функции и при необходимости передача параметра (обычный вызов же)

()(jQuery) — в параметре передается jQuery

function($){} — а тут этот параметр объявлен и используется

(function($){})(jQuery) — итого, объявили анонимную функцию, и вызвали ее, передав параметром объект jQuery

Например, доллар у вас используется другой библиотекой, пусть MooTools.
Тогда вы запускаете jQuery в безконфликтном режиме

jQuery.noConflict();

Это значит, что доллар использоваться не будет, и объект будет доступен только по ссылке jQuery.

Но для удобства вы можете использовать анонимную функцию и безопасно использовать внутри неё переменную доллара

(function($){
  $('.slider').slick();
})(jQuery);

Чтобы стало совсем понятно, конструкцию можно переписать без анонимной функции

var myFunc = function($){
 // some code
}

myFunc(jQuery);

wikipedia говорит - в общем распространение изменений, как в формулах exсel таблиц

Excel - наверно самый показательный пример, когда вы меняете одну ячейку, то все зависимые ячейки пересчитываются (сами), зависимые ячейки от зависимых тоже пересчитываются и т.д. Т.е. получается такой поток/разлив информации. Для реализации исходная ячейка должна обладать списком всех зависимых ячеек (первого уровня/напрямую зависимых).

Если реализовывать такую таблицу в императивном стиле то после изменения одной ячейки нужно обходить все остальные ячейки и делать их пересчет (т.к. конечная ячейка сама тянет данные от которых зависит), после этого нужно делать ещё проход и ещё т.к. если более поздние ячейки изменяют более ранние ячейки, то ячейки зависимые от более ранних будут не актуальны. Вообщем это большая нагрузка и все будет тормозить в отличие от "точенного" изменения в реактивном стиле.

Надеюсь, что правильно понял Ваш вопрос.

Пример

Храню в БД фото с марса в формате HD, делаю запрос на 100 фотографии, задача - показать 100 фоток последовательно на экране.

Стандартный поход: делаю запрос к базе на 100 фотографии, жду 2 секунды, получаю массив из 100 фотографии,
итератором бегаю по коллекции и показываю картинки на экране
псевдокод:

pics = GetPicsFromDatabase();
foreach(var pic in pics)
  ShowPic(pic)

Реактивный подход: делаю запрос к базе на 100 фотографии и обработчику запроса задаю коллбек, обрабатывающий следующий элемент коллекции

псевдокод:

// somecode
GetPicsFromDatabaseReactive(NextPictureHandler);
// somecode
NextPictureHandler(Image pic)
{
  ShowPic(pic)
}

В первом случае мы сами явно вытягивали следующий элемент списка (pull), а во втором случае - источник данных сам вкидывал нам следующий элемент, когда он был готов (push).
В первом случае мы ждем, пока сформируется источник данных (как правило занимаем тред) и после этого сами ручками просматриваем результат, во втором случае источник данных сам нас уведомит, когда будет готов.

Что это нам дает?
Асинхронность - в UI например это дает отзывчивость)
Масштабируемость - источник данных (коллекция картинок) и приемник (наш псевдкод, показывающий картинки) не связаны, отсутствие связи дает нам возможность подключить хоть 10 обработчиков картинок (пример один в черно-белом выводит, другой сепию накладывает и т.п.)
Отказоустойчивость достигается тем, что если сдох первый обработчик, например в его треде вылетел эксепшн, который повалил тред (прошу прощения за грубый пример), то действие выполнится резервным обработчиком (мы же их можем навешивать хоть 10, правда?)

https://wiki.openstreetmap.org/wiki/Nominatim#Reve...
Пример

Возможно резкое падение связано с системой кеширования в ОС, в начале данные загоняются в ram, далее они упираются в лимит и медленно сливаются на диск. Новая БД - новый файл - отдельный кеш блок... - работает быстро в начале.

Было бы интересно проверить на рам диске, что-б исключить тормоза io, если памяти много.

Так же вставка должна происходить быстрее чем обновление (когда база пустая, идет как раз просто вставка).
Т.к. если размер обновления не помещается в старые размеры документа, то его нужно релокйтить.

"avgObjSize" : 37

С таким объемом документа процент эффективной информации снижается. Для этой задачи можете попробовать LevelDB или его прототипы, в теории будет экономней и быстрее раз в 10.

Если создать новую коллекцию и записывать в нее, то все работает как надо.
Записывается примерно по 300 документов в секунду.

Отключите ожидание результата, или пишите в параллель. У меня на ноутбуке примерно 10к в сек пишет в пустую коллекцию.