stricter Markdown linting (smaller line length)

Author: kolomenkin

.config/.markdownlint.yaml

@@ -11,5 +11,5 @@ MD009:
 
 # Line length
 MD013:
-  line_length: 140
+  line_length: 120
   tables: false

.editorconfig

@@ -30,4 +30,4 @@ ij_yaml_spaces_within_brackets = true
 [*.md]
 indent_style = space
 indent_size = 4
-max_line_length = 140
+max_line_length = 120

solution-notes-letter.ru.md

@@ -10,34 +10,40 @@
 А я ожидал, что результат уже должен быть лучше аналогов. Тем более, что у меня специализированный алгоритм,
 а у grep синтаксис иной и алгоритм по определению хуже должен быть.
 
-Потом я заменил алгоритм матча строки с динамическим программированием и памятью O(P*N) на другой, более быстрый и с константной памятью.
-И... я стал медленнее grep всего в 2 раза. Почти успех :))) При этом по профайлеру релизному у меня 80+% проводилось именно в матче строк.
+Потом я заменил алгоритм матча строки с динамическим программированием и памятью O(P*N) на другой,
+более быстрый и с константной памятью. И... я стал медленнее grep всего в 2 раза. Почти успех :)))
+При этом по профайлеру релизному у меня 80+% проводилось именно в матче строк.
 
 Не буду томить, сомневаюсь, что более эффективный алгоритм существует для этой задачи.
-Победить grep вышло лишь добавив несколько оптимизаций, которые просто ускоренно прокручивали алгоритм в популярных сценариях.
-Это ускорило матчинг примерно в 6 раз, а общее время работы программы раза в 3. И эта дало победу над grep всего лишь на 25-35%.
+Победить grep вышло лишь добавив несколько оптимизаций, которые просто ускоренно прокручивали
+алгоритм в популярных сценариях. Это ускорило матчинг примерно в 6 раз,
+а общее время работы программы раза в 3. И эта дало победу над grep всего лишь на 25-35%.
 
 После этого согласно профайлеру почти ровно половина времени проводилась
 в матче строк, а процентов под 40 времени проводилось в синхронном ReadFile().
 
 Я решил, что вот он звёздный час асинхронного чтения файлов!
 Запрограммировал, и... ничего. Общее время работы не изменилось.
-Но профайлер показал перераспределение времени в сторону алгоритма матча. Очень странно, что он замедлился. Я так и не понял почему так.
+Но профайлер показал перераспределение времени в сторону алгоритма матча.
+Очень странно, что он замедлился. Я так и не понял почему так.
 Я убеждён, что эти 40% можно было сжать до максимум 5% за счет параллелизации вычитки данных и их обработки.
-Возможно это как-то связано с тем, что данные лежат в файловом кэше, а не читаются с диска (более короткий путь IRP).
+Возможно это как-то связано с тем, что данные лежат в файловом кэше,
+а не читаются с диска (более короткий путь IRP).
 Возможно это банальное копирование памяти в kernel mode плохо параллелизуется.
 Может стоило переписать, чтобы чтение с диска в выделенном потоке выполнялось...
 Если у вас есть идеи почему так вышло или в чём ошибка, то буду рад если поделитесь.
 
 Также заметил вставку перед циклом команды nop при оптимизации по скорости компилятором.
-Есть лишь предположения зачем. Если вы вдруг знаете - тоже дайте знать. Есть скриншот, приложил его в проект.
+Есть лишь предположения зачем. Если вы вдруг знаете - тоже дайте знать.
+Есть скриншот, приложил его в проект.
 Я спросил моих разных коллег, они не в курсе.
 
 Попробовал на всякий случай отображать файл на память.
 Но у меня были сомнения в эффективности скорости подгрузки новых страниц в этом решении.
 Так и вышло. Немного медленнее, процентов на 20% (время всей программы).
 Хотя тоже странно при прогретом кэше.
-Теоретически, если данные в кэше лежат, то можно было бы их отобразить на виртуальную память в read-only режиме за O(1),
+Теоретически, если данные в кэше лежат, то можно было бы их отобразить
+на виртуальную память в read-only режиме за O(1),
 а потом экономить на переходах в kernel mode + экономить на копировании памяти.
 
 ## Тестирование и заметки
@@ -57,12 +63,15 @@
 В последней версии grep показывает 2.5 секунды, а моё решение - 1.6 секунды на тестовых данных.
 
 **ДОПОЛНЕНО:**
-Реализовал также чтение файла в отдельном потоке. Файловая операция синхронная, синхронизация с потоком lock free (spinlock).
-Получил общий выигрыш в 25% относительно решения на синхронном и асинхронном API (1.2 секунды). Итого в 2 раза быстрее чем grep.
+Реализовал также чтение файла в отдельном потоке. Файловая операция синхронная,
+синхронизация с потоком lock free (spinlock).
+Получил общий выигрыш в 25% относительно решения на синхронном и асинхронном API (1.2 секунды).
+Итого в 2 раза быстрее чем grep.
 
 ## Особенности реализации
 
-В итоге у меня остались все три реализации чтения файлов. Я оставил асинхронную версию как самую перспективную. Переключаются так:
+В итоге у меня остались все три реализации чтения файлов.
+Я оставил асинхронную версию как самую перспективную. Переключаются так:
 
 ```cpp
 #if 0
@@ -84,7 +93,8 @@
 
 Как и в условии задачи, основное консольное приложение собрано с отключенными исключениями и заодно без RTTI.
 
-Я притянул часть STL на мой страх и риск. Ту часть, которая не требует исключений и работает без лишних накладных расходов.
+Я притянул часть STL на мой страх и риск.
+Ту часть, которая не требует исключений и работает без лишних накладных расходов.
 Не вижу смысла не пользоваться дешевыми абстракциями, позволяющими писать более чистый код
 и более защищенный от ошибок программиста. И без велосипедов.
 Я имею в виду всякие std::unique_ptr, std::string_view, std::optional.