Почему компилятор Rust работает так медленно и как с этим бороться

Стейблкоины

Rust — современный системный язык программирования, который постоянно набирает популярность благодаря своей надежности, безопасности и высокой производительности. Однако одна из распространенных жалоб среди разработчиков — это медленная работа компилятора Rust (rustc), особенно при сборке больших проектов или при использовании Docker-контейнеров. Понимание причин этих долгих сборок и способов их оптимизации поможет существенно улучшить рабочий процесс и сократить затраты времени. Основные сложности возникают при компиляции больших бинарников, особенно когда сборка происходит с активацией таких опций, как Link Time Optimization (LTO) и включение полного отладочного символьного отладчика. Эти настройки позволяют получать более компактные и оптимизированные бинарные файлы, но при этом сильно увеличивают время компиляции.

В конкретных ситуациях, связанных с созданием статически связанных бинарников для web-сервисов, время построения может достигать нескольких минут — в одном из опытов полный билд длился почти четыре минуты, что не приемлемо при активной разработке. Одним из характерных моментов использования Rust в современных CI/CD пайплайнах и контейнерных инфраструктурах является появление новой проблемы — кэширование зависимостей внутри Docker. Стандартный способ сборки, при котором весь код и зависимости копируются в промежуточный слой для сборки, приводит к тому, что при малейших изменениях кода весь проект компилируется заново, включая сотни зависимостей, что критически замедляет процесс. Для решения этой задачи появилась популярная утилита cargo-chef, которая создает отдельный кэш шаг сборки для зависимостей, позволяя повторно использовать их в будущем, если файл рецепта зависимостей не изменился. Однако, даже при правильной организации с помощью cargo-chef большая часть времени сборки уходит на компиляцию именно конечного бинарника, а не зависимостей.

Анализ с помощью инструментов временной разбивки cargo --timings и профилирования самого rustc (с помощью флага -Zself-profile) показал, что наиболее ресурсоемкими этапами являются оптимизации, выполняемые LLVM в рамках процесса кодогенерации и LTO. Особенно выделяются такие этапы, как LLVM_lto_optimize, LLVM_module_codegen_emit_obj, и LLVM_thin_lto_import. LTO – это техника, позволяющая LLVM проводить глобальные оптимизации уже после этапа генерации отдельных объектных файлов, работая с объединённым кодом всего проекта, что улучшает конечное качество. При этом существует несколько уровней LTO: выключенный, тонкий (thin) и жирный (fat). Оказывается, активное использование fat LTO может увеличить время компиляции в четыре раза по сравнению с отсутствием LTO, а даже thin LTO значительно замедляет сборку.

Помимо LTO влияет и включение отладочных символов: режим debug = full, популярный для более удобной отладки, многократно увеличивает время компиляции и размер бинарника. При отключении LTO и отладочных символов время компиляции падает до приемлемых значений около 50 с, что для сайта с малой нагрузкой вполне нормально. Оптимизации LLVM в основном сосредоточены в фазе OptFunction и InlinerPass. Последняя выполняет агрессивное внедрение функций (inline) — процесс, довольно затратный по времени на больших проектах с большим количеством инлайнов. Путем тонкой настройки параметров инлайнинга (например, снижая порог thresholds с дефолтных значений до 10) удается заметно сократить время компиляции.

Кроме этого, большая часть времени тратится на оптимизацию замыканий и больших асинхронных функций. Rust компилирует асинхронные функции, как вложенные замыкания, что приводит к сложным и обширным объектам для компилятора. Разбиение больших асинхронных функций на более мелкие части не всегда помогает и может даже ухудшить компиляцию. Однако применение техники "стирания" Future за счет упаковки в Pin<Box<dyn Future>> помогает упростить состояние и сократить время оптимизации. Интересный подход — использование продвинутого формата манглинга символов v0, который позволяет получать более подробное и точное профилирование, выявлять конкретные функции, все еще замедляющие компиляцию.

Благодаря этому удается определить и сконцентрировать усилия на крупных тяжелых функциях в проекте. Следует отметить, что и сами зависимости влияют на сборку. Иногда в программу затягиваются генерики из библиотек, и оптимизация этих генериков происходит в контексте основного проекта, увеличивая время сборки. Включение флага -Zshare-generics позволяет повторно использовать инстанциации генериков из зависимостей, что уменьшает время оптимизации на финальном этапе, несмотря на возможное негативное влияние на кодогенерацию. Еще одним значительным фактором является выбор базового образа окружения для сборки в Docker.

Альпийские образы с musl libc и их аллокаторами памяти, часто используемые из-за их компактности, могут заметно замедлять время сборки. Переход на образ с Debian и стандартным glibc вместе с нестандартным аллокатором (например, mimalloc) позволяет сократить общее время компиляции в несколько раз — в одном случае с 29 секунд до критически низких 9 секунд. Методы оптимизации времени компиляции Rust можно условно разделить на несколько направлений. Во-первых, разумное конфигурирование профилей сборки, отключение LTO и отладочных символов там, где это возможно, а также использование снижения уровня оптимизации для финального бинарника (opt-level=0) при сохранении высокоэффективных настроек для зависимостей. Во-вторых, тонкая настройка параметров компилятора через RUSTFLAGS и -C llvm-args для уменьшения агрессивного инлайнинга, снижения порогов и изменения поведения оптимизаций.

В-третьих, рефакторинг собственного кода — разделение огромных асинхронных функций, избавление от излишних замыканий и использование приемов с Box::pin для упрощения будущих состояний. Для развивающихся проектов важно использовать современные инструменты профилирования и анализа компиляции, вроде measureme, flamegraph, summarize и chrome tracing. Они помогают визуализировать узкие места, слои перекрытия времени и глубину вхождения функций, что позволяет целенаправленно работать над оптимизацией. Автоматизация этих процессов и интеграция с CI/CD станет бесценным подспорьем для поддержки скорости разработки. Наконец, важным выводом является то, что большинство причин «медлительности» компилятора Rust связаны не с самим языком или rustc в изоляции, а со сложностью LLVM оптимизаций, агрессивным использованием LTO, составом зависимостей и, порой, неэффективным использованием асинхронных конструкций в коде.

Адекватное сочетание инструментальных средств, грамотных настроек и принятие компромиссов в оптимизации позволяет добиваться приемлемых времен компиляции. В целом, несмотря на сложность внутренней работы компилятора Rust, профессионалы сообщества уже создали множество полезных подходов для ускорения сборок. В ближайшем будущем ожидаются дальнейшие улучшения в rustc и LLVM, а также утилиты, способные автоматически выявлять и рекомендовать улучшения в структуре проектов. А пока разумное использование флагов компиляции, грамотное разбиение кода и адекватный выбор окружения значительно помогут ускорить процессы, сделали Rust еще более привлекательным для промышленного использования.