You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, i just saw the Developer Voices podcast with Keavon and Dennis, where @Keavon asked for tips/tricks to speed up the development workflow regarding Rust compile times (specifically, at 1:02:54). I have some ideas which work for other projects, though i have not compiled graphite yet - i can't say any of these will actually help, though i plan on testing it next time i get the chance.
Implement something like the dynamic_linking feature of Bevy engine docs which re-exports the engine (which in your case would be the core crates and dependencies) using a dylib to allow for less code needing to be statically linked. source (kinda)
cargo configs to test and document/recommend to contributors:
Using the mold linker. I see you have a shell.nix which uses mold as a linker, but nothing else. (note: the mold linker is entirely separate from the npm/node tool also called mold)
Using the multithreaded frontend with Rustflags -Zthreads=0 (automatic thread count) or -Zthreads=8 (important to test this, it can be slower)
Using the cranelift codegen backend, at least for some crates. You can compile dependencies and performance-critical crates with llvm while compiling other crates with cranelift. IME, Cranelift is not noticeably slower with opt-level=3, and generates worse performing binaries, so i always set opt-level=3 for building with cranelift.
Compiling proc-macros and their dependencies with opt-level=3 by setting it in [profile.dev.build-override] and [profile.dev.package.syn] (or just ..package."*" for setting it for all dependencies)
Of course it always makes sense to try various settings with cargo build --timings to see where time is spent, and maybe cargo build --verbose which logs out reasons why a crate might be re-built (Fresh/Dirty).
The above represent the options i've used across various projects, mostly Bevy (with these, i get 0.5s incremental compile times for bevy-based projects!). Theres various other ways to improve compile times, heres a few helpful links. These also discuss some code changes, which i don't have experience with:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi, i just saw the Developer Voices podcast with Keavon and Dennis, where @Keavon asked for tips/tricks to speed up the development workflow regarding Rust compile times (specifically, at 1:02:54). I have some ideas which work for other projects, though i have not compiled graphite yet - i can't say any of these will actually help, though i plan on testing it next time i get the chance.
dylib
to allow for less code needing to be statically linked. source (kinda)mold
linker. I see you have a shell.nix which usesmold
as a linker, but nothing else. (note: the mold linker is entirely separate from the npm/node tool also called mold)-Zthreads=0
(automatic thread count) or-Zthreads=8
(important to test this, it can be slower)opt-level=3
by setting it in[profile.dev.build-override]
and[profile.dev.package.syn]
(or just..package."*"
for setting it for all dependencies)Of course it always makes sense to try various settings with
cargo build --timings
to see where time is spent, and maybecargo build --verbose
which logs out reasons why a crate might be re-built (Fresh/Dirty).The above represent the options i've used across various projects, mostly Bevy (with these, i get 0.5s incremental compile times for bevy-based projects!). Theres various other ways to improve compile times, heres a few helpful links. These also discuss some code changes, which i don't have experience with:
Beta Was this translation helpful? Give feedback.
All reactions