Общий прогресс

Измерения за период с 29 июля по 28 сентября 2026 года доступны в системе измерений.

Среднее снижение wall-time составило 4,57% за два месяца — это замечательный результат. Из 629 измерений производительности 555 показали улучшения, и только 74 регрессировали. Ряд бенчмарков продемонстрировал двузначное снижение времени компиляции. В теории оптимизации это называется «море зелени».

rustdoc

Ной Лев добился значительного прироста скорости rustdoc. Недавно он опубликовал подробный отчёт об этом улучшении — стоит прочитать интересный и детальный анализ.

Clippy

PR #159642: Якуб Беранек включил PGO для Clippy, получив улучшение wall-time на большинстве бенчмарков Clippy — в лучших случаях на 18%!

Обновление LLVM

PR #158734: Никита Попов обновил версию LLVM, используемую компилятором, до версии 23. При обновлениях LLVM часто появляются улучшения скорости, и на этот раз среднее снижение wall-time составило 1,2% на всех бенчмарках. Это может показаться небольшим, но для единственного PR это действительно впечатляющий результат. Спасибо команде LLVM!

Новый borrow checker

Новый borrow checker Polonius Alpha (никак не связан с Наполеоном Dynamite) был включен на Nightly. Он точнее существующего borrow checker'а и принимает некоторые валидные программы, которые старый borrow checker отклонил бы. Однако этот чекер выполняет больше работы, что на меньшинстве проектов создаёт заметный прирост времени компиляции — включая популярный крейт serde. К счастью, Джек Юи работает над решением этой проблемы.

PR #161938: Джек сделал некоторые вычисления живости ленивыми, что снизило количество инструкций для serde на 3–5%, и на некоторых других бенчмарках менее чем на 1%.

PR #163027: В этом PR изменена структура данных и отрегулировано инлайнинг, что привело к уменьшению количества инструкций менее чем на 1% на большинстве бенчмарков.

Остаётся ещё работа по снижению оставшихся регрессий Polonius Alpha, но стоит отметить, что «море зелени» свидетельствует о том, что эти регрессии были перекрыты множеством других недавних улучшений.

Новый trait solver

Новый trait solver Penelope Hammertime [прим. редакции: это правда?] также был включен на Nightly.

Да, последние месяцы были очень активными.

Как и новый borrow checker, новый trait solver медленнее на меньшинстве проектов. Яна Дёнзельманн написала подробный отчёт о работах по повышению производительности нового solver'а.

Отчёт Яны достаточно детальный, поэтому я не буду повторяться про масштабные текущие работы, но упомяну PR'ы, над которыми работал сам:

PR #160479, PR #160605, PR #160801, PR #160892, PR #161077 и PR #161211.

Некоторые из них значительно сократили время компиляции для определённых крейтов: 50% на одном, 25% на другом, 15% на третьем, и даже больше на одном стресс-тесте. И я не единственный, кто добился прогресса в этом направлении — обязательно прочитайте отчёт Яны.

xmakro

Новый участник xmakro продолжил свою серию удачных улучшений.

PR #157281: xmakro оптимизировал обработку impl при построении графа специализации. Это дало среднее снижение количества циклов на 1,58% на всех бенчмарках — огромный результат для одного PR.

PR #158059: xmakro оптимизировал один аспект загрузки данных инкрементальной компиляции, снизив количество инструкций на нескольких бенчмарках — в лучших случаях на 6%.

PR #160473: xmakro избежал некоторых выделений памяти в горячей трассе обработки obligations, что снизило количество инструкций на множестве бенчмарков — в лучших случаях на 2%.

PR #160268: xmakro избежал массовых выделений памяти, переключив код выбора между старым и новым trait solver'ом со статической диспетчеризации. Это дало в основном снижение менее чем на 1% количества инструкций на ряде бенчмарков. Эта горячая трасса выделения памяти проявлялась в профилях уже давно, и я ранее пробовал точно такую же идею. Однако получил регрессию на паре бенчмарков — возможно, из-за немного других выборов в размещении некоторых атрибутов #[inline]. Хорошо, что эту явную неэффективность наконец исправили.

Анализ потоков данных

PR #160193: Изменён алгоритм обхода CFG, используемый анализами потоков данных в компиляторе. Эти анализы итерируют до фиксной точки, и алгоритм обхода влияет на скорость достижения фиксной точки. Для большинства кода новый алгоритм не даёт разницы, но крейт cranelift-codegen имеет одну огромную функцию с более чем 18 000 базовых блоков. Старый алгоритм требовал 1,5 миллиона вызовов apply_effects_in_block для достижения фиксной точки анализа EverInitializedPlaces, используемого borrow checker'ом; новый алгоритм требует 90 000. Это дало огромное ~30% снижение wall-time для build-операции check этого крейта.

PR #160033: Сделан EverInitializedPlaces более эффективным, на этот раз путём отказа от отслеживания ненужных данных для проекций. Это снизило количество инструкций на бенчмарке match-stress на 17%, и на нескольких других бенчмарках менее чем на 1%.

LLM'ы

Они стали очень хороши в определённых видах анализа. Я по-прежнему пишу весь свой код и текст вручную, потому что это (a) критически важно и (b) политика проекта требует этого. Однако получил полезную помощь LLM'а в анализе нескольких PR'ов, упомянутых в этом посте.

Разное

PR #160535: Крис Дентон увеличил стандартный размер стека, используемый компилятором, что позволило удалить ensure_sufficient_stack — механизм ручного расширения стека, разбросанный по местам, подверженным высокому уровню рекурсии. На этот PR было много обсуждений, потому что сложно решить, как лучше всего справиться с исчерпанием стека. Но эффекты производительности ясны: снижение количества инструкций на множестве бенчмарков — в лучших случаях на почти 3%.

PR #160506: В проекте используется много «rollup» PR'ов, где несколько PR'ов объединяются. Это потому, что нет достаточной ёмкости CI для слияния каждого PR'а по отдельности. Обычно PR'ы, которые влияют на производительность, объединяются самостоятельно, чтобы можно было чётко измерить их влияние. Впервые в истории проекта, в один момент было так много PR'ов с улучшением производительности, ждущих в очереди слияния, что Джонатан Бровер создал rollup, содержащий 10 улучшающих производительность PR'ов, чтобы дела шли вперёд! Это хорошая проблема. Позже был создан PR #162859, содержащий четыре PR'а с улучшением производительности. (Не нужно беспокоиться о неожиданных побочных эффектах, потому что у проекта есть возможность запустить бенчмарк-сьют производительности на отдельных PR'ах после слияния, чтобы убедиться, что каждый PR имел ожидаемый эффект производительности.)

PR #162747: Сделаны небольшие улучшения кода, который понижает AST до HIR. Это была очистка, которая не ожидалась повлиять на производительность, но она снизила количество инструкций на множестве бенчмарков — в лучших случаях на 1,5%. Иногда везёт.

Статус

Завтра начинается работа в Hexcat над проектом оптимизации производительности компилятора. Это захватывающе! Большое спасибо Маре Бос, Предрагу Груевски и всем остальным, кто помог сделать это возможным.

Постскриптум редактора

Имя нового solver'а — не Penelope Hammertime; это была шутка.

Постскриптум автора

Его настоящее имя Pineapple Häagen-Dazs.