Продолжаем тему https://t.me/itpgchannel/4165 "#LLM позволяют автоматизировать то, что раньше было автоматизировать невыгодно", и, одновременно тему "одна программа проводила 20% всего CPU time в работе с map"!

Я, знаете ли, performance freak. Могу задрачивать лишние пару процентов перфа неделями, если вижу профит в этом.

Perf оптимизациями я, так или иначе, занимаюсь последние лет 20, как на работе, так и для себя. Думаю, будет вполне уместно сказать, что в Я мало высокопроизводительного кода, к которому я когде-то не прилагал усилий.

Вот, #LLM позволяют погружаться в такие бездны perf оптимизации, которые раньше были out of scope, потому что удельная полезность их была невелика.

В своем крестовом походе против "20% всего CPU time в работе с map" я дошел совсем уже до мелочей.

Например, 50к лукапов было в таблицу парсеров по расширению файла. Понятная задача - найти для файла подходящий ему парсер.

Казалось бы, 50к не очень много, но с 40 миллионов лукапов я уже спустился до 500к лукапов на всю программу, и 50к стало уже заметно на общем фоне.

Раньше я бы на этом и остановился, потому что овчинка выделки не стоит.

А тут я просто написал клоде "так, строй perfect hash, первый диспатч по длине расширения, второй - по линейной комбинации букв расширения, брутфорс для поиска минимума операций. Скрипт с генератором положи в dev/, так же туда перенеси список всех расширений, чтобы его можно было менять только через regen".

Через 5 минут у меня был готов скрипт-генератор https://github.com/pg83/ay/blob/master/dev/gen_parsers.py, и очень быстрый лукап парсера по расширению файла - https://github.com/pg83/ay/blob/master/parsers_generated.go#L74, раза в 2 быстрее обычного поиска в таблице.

Мораль? Как обычно, ее нет!

#perf