Статья написана исключительно в развлекательных целях. Любой администратор любой информационной системе знает, что мест для автоматизации в его работе бесконечное множество. Какая огромная ниша для автоматизации прячется в задачах обработки логов, сбора статистики, реакции на события систем.  Вот однажды и моего коллегу утомило обрабатывать гигабайты логов exchange сервера, чтобы найти нужные данные. Вполне здравая мысль посетила его светлый ум – «Куда как проще работать с данными если они лежат в какой ни будь БД». И не мудрствуя лукаво он лихо наваял скрипт на том что было установлено на его свеженьком Linux. Так появился первый скрипт на python который занимался складированием логов в MongoDB. Через какое-то время в разговоре со мной он вскользь упомянул про этот механизм и изъявил желание переписать его на JS. Мне мысль понравилась, и я предложил написать этот скрипт на всем что есть под рукой. Чем мы и занялись в обеденные перерывы. Для тестирования мы выбрали 545 json файла общим размером 1Гб. Количество документов в них примерно 687 тысяч.  В качестве сервера БД была выбрана MongoDB. Дополнительные требования: Так как экспортер логов exchange-а хранит дату в каком то совершенно непотребном виде (“Timestamp“:  “\/Date(1649404808029)\/“), необходимо было привести эту запись к тому который понимает Mongo. Если поле “MessageLatencyType” имеет значение отличное от 0, то заменить значение поля MessageLatency на MessageLatency. TotalMilliseconds. Вот пример этих полей: Стараться использовать только нативные или официальные инструменты для работы с JSON и Mongo. Без читерства ))) Что же оказалось у нас под рукой? В сущности, питон прекрасно подходит как для повседневных административных задач, так и  для конкретно этой. В качестве драйвер использовался pymongo.   Прекрасный и очень шустрый язык. Устанавливаем драйвер БД и вперед.  К сожалению официальных драйверов под PS я не нашел, поэтому пришлось брать то что есть: Install-Module Mdbc. Данный проект не новый, но он до сих пор не имеет реализации, столь нужного, командлета как InsertMany. Поэтому придется обходится «построчной» записью. Это конечно намного медленнее, но для наших нужд вполне подойдет. Для работы с JSON будем применять JavaScriptSerializer из стандартной библиотеки System.Web.Script.Serialization.  Седьмая версия PS обладает всеми недостатками предыдущей версии. Но имеет существенное отличие, а именно собственный конвертер для JSON. Забегая вперед скажу, что он довольно-таки неповоротливый.     Признаться, я возлагал большие надежды на этот язык. Но о результатах мы порассуждаем чуть позже. А пока немного кода  Во время работы на Go меня почему то посетила ностальгия. Вспомнилось как около 25 лет назад меня приводили в замешательство слова про указатели )) Оказывается, в руби очень удобно работать с многопоточностью. И не смотря на то что в остальных версиях мы делали все в один поток, на руби я сделал форк который умеет работать в несколько потоков. И так, не забываем про gem install mongo и вперед:  В качестве сериализатора Json использовался Newtonsoft взятый NuGet-ом. Драйвера для Mongo официальные, взяты оттуда же.  Код на java получился самый объемный. Для работы с json применялась легкая библиотека com.github.cliftonlabs:json-simple     И так. Для чего же мы все это делали? На самом деле, ни для чего ))). Просто это достаточно легкая задача для того что бы попробовать что-то новое, какой-то новый язык. Понять его удобство, или скорость разработки, или красоту цветовой палитры, ну или любой другой субъективный параметр. Но коль уж мы потратили столько времени, давайте все-таки сделаем какие-то количественные выводы.  Хм… Что же вызывает такую большую разницу в скорости?  Для ответа на этот вопросы мы условно разделили программу на части: работа с файлами работа с JSON работа с БД На каждую часть повесили по таймеру и стали наблюдать. Оказалось, что практически в любом языке самым медленным является работа с объектами JSON.  Замена целого объекта MessageLatency на поле типа int самая долгая операция в любом языке и библиотеке по работе с JSON, кроме JS. Не представляю, как JS работает с объектами JSON, но выглядит так как будто он вообще не заморачивается десериализацией, и работает с ними как с массивами строк. А вот внеконкурсные результаты работы в несколько потоков на языке Ruby. Многопоточный Ruby обошел Go по скорости. Хотя это конечно читерство, но все равно приятно )) Как я и говорил в начале, статья написано исключительно в развлекательных целях. Думаю, она вполне подойдет для легко чтива под чашку чая.  Исходя из вышесказанного не стоит искать здесь какой-то истины, ровно как и не стоит принимать полученные данные в качестве призыва к выбору инструмента разработки.  Что касается меня, то я сделал то что давно хотел - в первый раз попробовал Ruby и Go, а также посмотрел по пристальней на Java. Ruby оказался очень интересным языком, вероятно я продолжу общение с ним. Мой основной инструмент работы (PS7) оказался в топе, жалко что с конца :-) Надеюсь кому-то это было интересно :-) Всем спасибо за внимание.  Системный администратор