v0.25

Author: kolomenkin

README.md

@@ -0,0 +1,66 @@
+# ЗАМЕТКИ ПО РЕШЕНИЮ
+
+## Процесс решения
+
+Во-первых было интересно, спасибо! :)
+Выполнение заняло сильно больше времени, чем я изначально оценил.
+
+Было весьма унизительно, когда первая версия казалось бы очень оптимизированного решения со всякими 
+статически выделенными массивами без перевыделений памяти оказалась медленнее grep раз в 5-6.
+А я ожидал, что резальтат уже должен быть лучше аналогов. Тем более, что у меня специализированный алгоритм,
+а у grep синтаксис иной и алгоритм по определению хуже должен быть.
+
+Потом я заменил алгоритм матча строки с динамическим программированием и памятью O(P*N) на другой, более быстрый и с константной памятью.
+И... я стал медленнее grep всего в 2 раза. Почти успех :))) При этом по профайлеру релизному у меня 80+% проводилось именно в матче строк.
+
+Не буду томить, сомневаюсь, что более эффективный алгоритм существует для этой задачи.
+Победить grep вышло лишь добавив несколько оптимизаций, которые просто ускоренно прокручивали алгоритм в популярных сценариях.
+И эта победа всего лишь на 25%.
+
+После этого согласно профайлеру почти ровно половина времени проводилась
+в матче строк, а процентов под 40 времени проводилось в синхронном ReadFile().
+
+Я решил, что вот он звёздный час асинхронного чтения файлов!
+Запрограмировал, и... ничего. Общее время работы не изменилось. 
+Но профайлер показал перераспределение времени в сторону алгоритма матча. Очень странно. Я так и не понял почему так.
+Я убеждён, что эти 40% можно было сжать до максимум 5% за что параллелизации вычитки данных и их обработки.
+
+Попробовал на всякий случай отображать файл на память.
+Но у меня были сомнения в эффективности для этого применения.
+Так и вышло. Немного медленнее. Примерно как grep вышло.
+
+## Тестирование и заметки
+
+Тестировал на логе веб сервера, 2 Гб, 5.5 млн строк, средняя длина строки 380 байт, все строки не длинее 1024 байт.
+
+Диск SSD, но прогревал чтобы всё в кэш легло файловый. 8 ядер логических core i5 gen8, прочей загрузки минимум, ноутбук.
+
+Сборка под x64 архитектуру работала быстрее вышла чем под x86.
+
+Флаг FILE_FLAG_SEQUENTIAL_SCAN к моему разочарованию не дал ничего.
+
+Иногда скорость надолго залипает на +25%, иногда на самом быстром варианте.
+Скорее всего связано с тем, что у меня ноутбук и у ядер есть режимы экономные. Но не факт.
+
+## Особенности реализации
+
+В итоге у меня остались все три реализации чтения файлов. Я оставил асинхронную версию как самую перспективную. Переключаются так:
+
+```
+#if 1
+#if 0
+    CSyncLineReader    _lineReader;
+#else
+    CAsyncLineReader   _lineReader;
+#endif
+#else
+    CMappingLineReader _lineReader;
+#endif
+```
+
+Также есть юнит тесты на базе gtest с отдельным проектом.
+
+Как и в условии задачи, основное консольное приложение собрано с отключенными исключениями и заодно без RTTI.
+
+Я притянул часть STL на мой страх и риск. Ту, часть, которая не требует исключений и работает без лишних накладных расходов.
+