Rust на ноутбуке: почему Cargo собирает долго и как ускорить сборку в разы

Прямой ответ

Rust компилируется дольше Go и большинства интерпретируемых стеков — это плата за мономорфизацию дженериков и проверки на этапе компиляции. Но «долго» управляемо: инкрементальная компиляция (включена в dev-профиле по умолчанию) делает повторные сборки секундными, sccache кэширует компиляцию между проектами и CI, а разделение dev/release-профилей не даёт оптимизациям тормозить итерации. Ресурсы: rustc отдельных тяжёлых крейтов потребляет 1–2 ГБ RAM, полная холодная сборка среднего проекта с tokio/serde-стеком — 1–3 минуты на 6–8 ядрах; 16 ГБ ОЗУ — практический минимум, 32 ГБ — комфорт для крупных workspace.

Почему Rust медленный на сборке: честная механика

1. Мономорфизация: каждый конкретный вариант дженерика компилируется отдельно — код оптимален в рантайме, дорог в компиляции.
2. LLVM-оптимизации в release-режиме — основная статья времени; в dev-профиле они почти отключены (opt-level=0).
3. Граф зависимостей: cargo компилирует крейты последовательно по зависимостям — «широкие» деревья (много мелких крейтов) параллелятся хорошо, «глубокие» — хуже.
4. Проверки (borrow checker, трейты) — дешевле кодогена, но на макростях (proc-macro: serde, tokio) добавляют ощутимо.

Понимание этого снимает главную ошибку новичка: ждать от release-сборки скорости dev-сборки. Итерации — только в dev; release — перед прогоном бенчмарков и поставкой.

Ускорение итераций: практический набор

1. Инкрементальная компиляция — включена в dev; не отключайте её и не чистите target/ без причины: cargo clean обнуляет весь кэш сборки, следующая сборка — полная.

2. sccache — кэш компиляции по содержимому (аналог ccache):

cargo install sccache
# в окружении: RUSTC_WRAPPER=sccache

Выигрыш — на повторных сборках с чистым target (переключение веток, несколько клонов, CI): кэш переживает clean.

3. Dev-профиль под скорость в Cargo.toml:

[profile.dev]
opt-level = 1            # лёгкие оптимизации: рантайм терпим, сборка почти та же
[profile.dev.package."*"]
opt-level = 2            # зависимости — с оптимизациями (они меняются редко)

Приём «свой код без оптимизаций, зависимости — с оптимизациями» ускоряет рантайм dev-прогона, не удлиняя сборку ваших итераций.

4. Быстрый линкер: на Linux — lld/mold (конфиг в .cargo/config.toml), на macOS — lld; линковка на финальной стадии больших бинарников занимает десятки секунд, mold сокращает её кратно.

5. Меньше фич: каждое включение default-features = false и точечные фичи режут объём компиляции; аудит дерева — cargo tree -d (дубликаты версий) и cargo build --timings (наглядный отчёт, кто занял время).

Память и диск

• rustc на тяжёлых крейтах (большие трейт-реализации, proc-macro) берет 1–2 ГБ на процесс; параллельная компиляция N крейтов = N × потребление. На 8 ГБ ноутбуке холодная сборка крупного проекта уходит в swap — отсюда «Rust тормозит» на слабых машинах.
• target/ растёт до десятков гигабайт на workspace; чистка устаревших артефактов — cargo sweep или периодический cargo clean (осознанно). Кэш sccache — ещё 5–15 ГБ; держите диск с запасом 15–20%.
• rust-analyzer (LSP) — отдельный процесс на 1–3 ГБ в больших проектах; лимиты и диагностика языковых серверов — в статье про IDE и ОЗУ.

Windows-специфика

Ставьте тулчейн через rustup с toolchain stable-x86_64-pc-windows-msvc (не GNU-вариант): MSVC-сборка быстрее и совместима с экосистемой. Требования — Build Tools for Visual Studio (компонент C++). Антивирус исключите для target/ и ~/.cargo — эффект тот же, что для других тулчейнов. Кросс-компиляция с Windows под Linux возможна через cross (cargo install cross — использует Docker), что удобно сочетается с контейнерными привычками.

Сравнение ожиданий: Go против Rust на одном ноутбуке

Калибровка ожиданий полезна при выборе языка под задачу: холодная сборка CLI-утилиты — секунды-десятки секунд в Go против минут в Rust; инкрементальная итерация — сопоставимы (секунды) при настроенных профилях; рантайм-производительность и контроль памяти — преимущество Rust; скорость разработки и поставки — часто Go. Подробно сторона Go описана в статье про Go-тулчейн на ноутбуке. Для упаковки финального бинарника в минимальный образ — схемы multi-stage в материале про оптимизацию Docker-образов.

FAQ

Насколько 32 ГБ ускоряют Rust-сборку против 16? Прямо — никак (компиляция упирается в CPU/диск); косвенно — убирает swap при параллельной компиляции крупных workspace и оставляет место rust-analyzer. Если сейчас 16 ГБ и swap молчит — апгрейд сборку не ускорит.

Помогает ли cargo build -j N ограничить параллелизм? Да, на машинах с малой памятью: меньше одновременных rustc — ниже пик RAM ценой более долгой сборки. На 16 ГБ разумно -j 4..6 для тяжёлых проектов.

Что даёт PGO и стоит ли его использовать локально? Profile-guided optimization ускоряет рантайм на 10–20% ценой трёхпроходной сборки — имеет смысл для финальных релизов, не для dev-цикла.

Почему после обновления Rust всё пересобралось? Смена версии компилятора инвалидирует кэши — это разовая полная сборка. Фиксируйте версию через rust-toolchain.toml в проекте: команда и CI пересобираются синхронно, а не случайно.

Мини-сценарий: первая итерация и типичные грабли

Новый проект: cargo new app && cd app && cargo run — компиляция «hello world» занимает секунды, ожидания «Rust всегда медленный» на старте не оправдываются. Грабли приходят с ростом дерева зависимостей: добавили tokio, serde, axum — холодная сборка вырастает до минут, и здесь решают настройки из статьи выше (sccache, dev-профиль, быстрый линкер). Вторая волна граблей — работа в ветках: переключение с сильно отличающимся Cargo.lock сбрасывает инкрементальный кэш, и sccache становится главным спасением.

Практический совет по организации: держите тяжёлые зависимости обоснованно (cargo tree | wc -l на старте и через месяц — отрезвляющее сравнение), а в workspace выносите общие библиотеки — их повторная компиляция кэшируется между пакетами. И калибровка ожиданий: если время полной сборки переваливает за 5–10 минут на 8-ядёрном ноутбуке, это уже крупный проект — большинство же учебных и прикладных задач остаются в пределах минуты на инкрементальной итерации, что вполне сопоставимо с другими компилируемыми языками.

Стоит ли включать lto и codegen-units=1 в dev-сборках? Нет: это release-оптимизации, удлиняющие сборку в разы ради процентов рантайма. Их место в [profile.release] финального бинарника, а dev-профиль должен собираться максимально быстро.

Источники: документация Cargo и rustc (профили, инкрементальная компиляция, PGO) — ссылки в шапке.