Половину времени компиляции двух пакетов занимал memcpy, потому что элемент вектора весил 136 байт

Николас Незеркот, десять лет занимающийся производительностью компилятора Rust, подвёл 31 июля итоги восьми месяцев работы. Средняя экономия времени сборки с 3 декабря 2025 по 29 июля 2026 составила 5,59 процента, но примерно половину этого дал не сам компилятор, а генератор документации: там среднее время упало на 37,92 процента, а по всем его тестам суммарно на 28. Без учёта документации выигрыш компилятора 2,90 процента.

Самая наглядная история из отчёта как раз про memcpy. Автору показали пару пакетов, где новый решатель типажей резко тормозил. Профилирование через Cachegrind показало, что почти половина времени уходит на копирование памяти:

🔘 виноват оказался горячий вектор с элементом размером 136 байт: LLVM для значений больше 128 байт вставляет вызов memcpy вместо обычных инструкций;
🔘 автор убрал две трети перемещений и ужал тип до 104 байт, чтобы порог не срабатывал, и время сборки двух худших пакетов упало на 40 процентов;
🔘 отдельная линия — узлы синтаксического дерева: выражения ужали с 72 до 64 байт, чтобы они помещались в кэш-линию, и на деревоёмких тестах время упало более чем на 10 процентов, а доля промахов кэша до 29;
🔘 автор помнит времена, когда узел выражения весил 104 байта: хорошая производительность набирается такими шагами годами;
🔘 в Clippy нашлась классическая проблема виртуальных вызовов: сотни проверок, каждая объявляет несколько методов обхода, и на каждом узле дерева вызывались все, включая пустые. После объединения проходов время упало на 10–30 процентов, а неверные предсказания ветвлений — на 20–80, а на одном стресс-тесте на 97;
🔘 новый решатель типажей за три месяца прошёл путь с 27 секунд до менее чем секунды на одном из своих тестов.

Автор оговаривает, что цифры по Clippy получены локально: в постоянном замере на CI он пока не участвует. Забавная деталь про Clippy: параллельно ту же проблему нашёл другой человек и прислал более аккуратное решение на несколько дней раньше, так что правка автора не влилась.

Полная статья: https://nnethercote.github.io/2026/07/31/how-to-speed-up-the-rust-compiler-in-july-2026.html

@prog_stuff

Лимит одновременных транзакций подняли с тысячи до десяти тысяч, чтобы убрать ошибки, и получили шестнадцать минут деградации

Лиз ван Дейк из PlanetScale разобрала 7 августа инцидент, в котором продакшен-база MySQL складывалась на шестнадцать минут. Ошибки шли по нарастающей: на нулевой минуте 5 ошибок в минуту при 15 000 запросов в секунду, на десятой 1400 ошибок и 1500 запросов, потом транзакцию убил таймаут, накопленное разгреблось примерно за тридцать секунд, и пропускная способность подскочила до 8500.

Повод банальный: пакетная задача открыла транзакцию к горячей таблице, взяла блокировки строк и держала их пятнадцать минут без коммита. Интересно то, что происходило вокруг неё. Запросы, копившиеся следом, в основном на блокировках вообще не стояли: это обычные чтения, которым InnoDB отдаёт согласованный снимок. Но построение снимка требует пройти назад по истории версий каждой затронутой строки, а эта история росла все пятнадцать минут.

🔘 чтения, которые обычно занимают миллисекунды, начали упираться в потолок выполнения в 90 секунд, приложение повторяло их в тесном цикле;
🔘 за минуты внутри движка хранения скопилось больше десяти тысяч запросов, каждый восстанавливал всё более длинную цепочку версий;
🔘 чтения страниц обогнали способность буферного пула освобождать память, и падать начали запросы к совершенно другим таблицам, никак не связанным с заблокированными строками;
🔘 предыстория в том, что нагрузку переехали с прежней базы, где перед сервером стоял пул потоков: он ограничивал число одновременных запросов примерно тысячей, а остальных ставил в очередь на миллисекунды;
🔘 на новом месте пул при переполнении не ставит в очередь, а ждёт фиксированное время и возвращает ошибку. Приложение таких ошибок никогда не видело и обрабатывать их не умело, поэтому лимит подняли до десяти тысяч. Число выбрали не по расчёту, а потому что с ним ошибки прекратились;
🔘 лечение оказалось обратным: лимит вернули примерно к тысяче и заменили ошибку ожиданием в очереди с увеличенным таймаутом, то есть повторили поведение прежнего пула потоков.

На следующее утро конфигурация прошла проверку на другом шарде, который держит на порядок больше трафика: на пике около 25 тысяч заявок на слот в секунду при тысяче слотов, ноль ошибок и ровные 60 тысяч запросов в секунду. За весь день отклонена одна транзакция, а внутри MySQL в каждый момент выполнялось меньше двухсот команд: по закону Литтла это примерно три миллисекунды на запрос.

Автор оговаривает, что это не универсальный совет всегда зажимать параллелизм. Совет работает там, где есть пессимистичные блокировки и общее состояние: горячие строки, SELECT ... FOR UPDATE по популярным ключам, счётчики, балансы, очереди задач. И это не свойство MySQL: в PostgreSQL бывает то же самое, а роль ограничителя там играет PgBouncer.

Полная статья: https://planetscale.com/blog/concurrency-vs-throughput-vitess-mysql

@prog_stuff