Брент Роуз, партийный функционер говорящая голова сообщества РНР и автор очередного конкурирующего стандарта фреймворка Tempest, объявил конкурс, весьма вторичный, после эпичного One billion row challenge (который и сам по себе уже был вторичен, по отношению к оригинальному 1brc), но кто ж считает, когда на кону такие призы, как плюшевый слон от JetBrains!

История вопроса: некоторое время назад наш незадачливый разработчик вдруг обнаружил, что event sourcing, столь прекрасно выглядевший на бумаге, внезапно забуксовал при попытке реального применения концепции "один и тот же код для однократного вызова и для восстановления состояния по исходным данным АКА провернуть мясо в фарш заново". И выполняется, буквально сутками. И в итоге Брент засел за оптимизацию, открыв для себя такие крутые хаки для работы с MySQL, как множественный INSERT или оборачивание отдельных запросов в транзакцию.

При этом двух блог-постов на тему оптимизации ему показалось мало, да и к тому же новый фреймворк сам себя не разрекламирует. И в итоге появилась идея конкурса. Который к исходной задаче уже никакого отношения не имеет, а представляет собой банальный парсинг CSV.

Конкурс объявлен вчера и продлится две недели.

За первые сутки было подано около 80 заявок, из которых обработано 60. Разумеется, самый большой интерес вызывает лидер с конца, которому удалось превысить результат ближайших соперников болee чем в два раза. При беглом взгляде на его решение причина видится в том, что он перепутал конкурс по скорости с конкурсом по экономии памяти и зачем-то пишет все промежуточные результаты в файл, причём не один, а множество.

Далее довольно плотным пелетоном идут стандартные решения с результатами в пределах 100-150 сек, реализующие различные варианты построчного чтения. При этом видно явное преимущество использования stream_get_line(), которая в одном вызове объединяет функции чтения и парсинга. Также стоит присмотреться к stream_set_read_buffer().

Ну а в топе, с таймингами меньше 50 секунд, идут, разумеется, паралеллисты. Результаты которых довольно предсказуемы, и зависят в основном от того, сколько воркеров хватило наглости поставить. Впрочем, результат тройки лидеров даже на их фоне впечатляет - 6-7 секунд. И, похоже, код лидера стоит серьёзного изучения.

Но лично мне бы хотелось, чтобы было два разных зачёта - с параллельностью, и без. Чтобы видеть "чистые" оптимизации.