Slow compile times?

[jetp250]

(it seems I can't create an issue that doesn't have either the 'enhancement or 'bug' labels so maybe this is the place)

I'm trying to shave as much off my cold compiles as possible and right now, glam seems to be the biggest offender with 2-2.5s compiles? Maybe this is expected, but I found your blogpost from 2020 in which the crate compiles in ~0.8s on a 4th gen i7 Intel CPU. I'm compiling on a Ryzen 7900 with 32GB DDR5-6000 and a much faster SSD than the HDD in the blog, so I'm wondering if this is known and if something can be done about this on glam's side? (There is this article for end-user compilation-time improvements but a library can't do most of those)

I understand of course that the library has since accumulated a lot of new features, so maybe there really is nothing you can do, but might as well ask since nobody else has seemingly asked yet. Incrementals do seem okay fortunately.

Here is the result of cargo +nightly -Zsection-timings build --timings with dev opt-level=1, no other factors (also tested in a completely fresh empty project with only glam and it takes a similar amount of time):
cargo-timing-20260328T183602371Z-d93538c4ebb389a7.html

Edit: attached image for convenience

[CatCode79]

Only 2 seconds for glam compile time?
Bit jealous of yours—my cargo-timing is more like this:

My profile.dev on Cargo.toml is:
opt-level = 2 # Enable medium optimisations without sacrificing compilation speed too much.
debug = "full" # Generate maximum debug information for dev builds.
split-debuginfo = "unpacked" # Improve linking performance by keeping debug symbols separate (not for MSVC).
strip = "none" # Retain all symbol information for precise backtraces.
debug-assertions = true # Enable debug_assert! macros to catch logic errors early.
overflow-checks = true # Enable integer overflow protection (essential for dev builds).
lto = false # Disable Link-Time Optimisation to ensure rapid iteration.
panic = "unwind" # Maintain full stack unwinding for detailed crash reports.
incremental = true # Enable incremental compilation for faster rebuilds.
codegen-units = 2 # The fastest (on my pc); possibily due to reduced pressure on the (rust-lld) linker.

Noticing codegen-units = 2 was quite counter-intuitive for me—I only discovered it recently. It might be one of those 'it works on my machine' type of things. All my compile-time tests were done on an idle system; if I happen to watch a YouTube video while compiling, the build times skyrocket.

The HW is a laptop with an i7-12650H; not exactly the fastest thing on the market.

On config.toml (windows build) I have this flag:
# Omits LLVM bitcode to significantly speed up compilation.
# Note: This is only safe for Dev builds; Cargo defaults to 'yes'
# in Release to allow Link-Time Optimization (LTO) to function.
# Note: only applicable when LTO is disabled on Cargo.toml profile.dev section.
"-Cembed-bitcode=no",
And I'm using linker = "rust-lld.exe" instead of "link.exe" because it's faster.

If you haven't already, take a look at the nightly rustc or LLVM flags, as there might be some interesting options to improve build times (I'm on stable, so I haven't analysed them myself).
Generally, besides the compilation itself, linking times can be quite long, though it might not make much of a difference in a cold build.

I'm not exactly an expert on crate-level compile-time optimisations: perhaps reducing macro usage (especially procedural macros)? Or using optional dependencies? What stands out is that the front-end glam compile time takes up significantly more time than the codegen phase.

Just my two cents as a regular Rust user (I’ve never contributed to glam myself): I honestly think the compile-time issue should be solved at the root by the rustc contributors, rather than being delegated to individual crates. This is because it could force a shift in coding styles, finding a different trade-off between speed, usability, and code size, which might ultimately result in a worse final product.

[jetp250]

I honestly think the compile-time issue should be solved at the root by the rustc contributors, rather than being delegated to individual crates

Would be ideal, but I don't realistically foresee this happening since plenty of people have already poured in a lot of effort to speed rustc up. I'm not familiar with the rustc codebase but I totally expect there are no low-hanging fruits left at this point

Also, is a bit surprising to me that a gen 12 (laptop) i7 is taking 5-6x as long to compile glam o_O
Those compile times look ouch in general - I see you've done digging so maybe there's nothing new but, also for others reading this, check out the article I linked in the main post and Bevy's compilation speed tips if you haven't already in case there's something you haven't tried already
But ye, these tweaks are largely not something a library has control over

[CatCode79]

Would be ideal, but I don't realistically foresee this happening since plenty of people have already poured in a lot of effort to speed rustc up. I'm not familiar with the rustc codebase but I totally expect there are no low-hanging fruits left at this point

Actually, there are at least a couple of low-hanging fruits:
https://rust-lang.github.io/rust-project-goals/2025h1/parallel-front-end.html
https://rust-lang.github.io/rust-project-goals/2025h2/relink-dont-rebuild.html

There's also this one:
https://rust-lang.github.io/rust-project-goals/2026/build-std.html
Which MIGHT speed up compilation, but likely only for incremental builds.

Cranelift support has been dropped, so the dream of having an all-Rust compiler (and possibly a faster one) is currently on hold...

We’ll also have to see how the future borrow checker, Polonius, performs. For now, it's only in alpha, and it's not yet clear how much (or if) it will impact compile times.

Also, is a bit surprising to me that a gen 12 (laptop) i7 is taking 5-6x as long to compile glam o_O

Keep in mind that I always use my laptop on a balanced power plan, so it runs a bit slower to save battery.

In general, I think the compiler tries to maximize throughput by spreading the compilation of a single crate over time while parallelizing everything else. You can't see it in the image, but I have other significant crates being compiled in parallel, like ash and spirv-tools.

I used to be frustrated with zstd's compile times, but now I’ve switched to lz4_flex and I'm much happier.

Those compile times look ouch in general - I see you've done digging so maybe there's nothing new but, also for others reading this, check out the article I linked in the main post

Thanks for the link! I had forgotten about this one:
https://corrode.dev/blog/tips-for-faster-rust-compile-times/#use-a-scratch-disk-for-faster-builds
It's tempting, but if I recall correctly, that's a solution more useful for Linux than Windows.
Though there might be hope here:
https://devblogs.microsoft.com/visualstudio/devdrive/

I'm already making good use of this hint:
https://corrode.dev/blog/tips-for-faster-rust-compile-times/#split-big-crates-into-smaller-ones-using-workspaces
I split crates by their big dependencies, like wgpu, and wrap them to isolate them from other crates. This makes everything much more parallelizable.
Essentially, my structure is the exact opposite of Bevy's (more like raylib instead). Since my pet project is a game and not an engine, it's much easier to isolate the crates (usually, I pass data between crates as Vec_u8 (GPU data, files, etc.) instead of having shared types in a common crate).

[bitshifter]

Hi, thanks for the report. It has been a long time since I checked build times and yes, glam has got a lot more features since 2020, mostly all the integer vector types which while simple, are a lot of code.

Do you have any glam features enabled?

One thing I could do is make the integer types opt in, or opt out. Ultraviolet made f64 and int types opt in (I don't think they added all of the int types that glam has).

It's something I could consider, I don't think I'd want to make it too fine grained because it would be a pain to maintain but wholesale disabling all int types wouldn't be too bad and would probably give 2020 compile times if you don't need integer types.

I am kind of assuming it's the sheer amount of code in glam that is the problem, but if there's any way of getting more info out of cargo timings that might be useful.

[jetp250]

I have bytemuck and std enabled, but cargo new glam-test && cd glam-test && cargo add glam && cargo build gives similar timings (seems like pretty exactly 2.0s on repeated cargo clean && cargo build runs, if cargo's timings are to be trusted) which only has std enabled. Adding bytemuck brings that to 3s but only because it includes bytemuck's compilation, glam's build times appear to not have changed:

For the integer types - I don't know if I've ever used 8- and 16-bit int vectors, or even the 64-bit one, but IVec3 is something I very frequently use, so would be unfortunate to have to bring all of the rest just for that - any chance IVec3 could be included by default and rest are behind the gate? Would of course be a bit inconsistent though and I don't know how many make use of IVec3

The file I attached in the original post has the most information I think we can get out of cargo timings right now (it already uses the nightly -Zsection-timings flag), which is not a lot. Then there's the ultra-detailed cargo rustc -- -Zself-profile, but unfortunately that only profiles the crate you're building and completely excludes dependencies, so the only option is to clone glam and try to profile building there.

For reasons I don't yet understand it consistently takes longer to build than when used as a dependency -- ~2.8s instead of 2.0s -- but here are..

• .. the ultra-detailed -Zself-profile timings displayed with summarize: https://pastebin.com/raw/7Jbraupi
• .. same but with flamegraph (see summarize link above for how I got it): needs to be downloaded and opened in browser for it to be interactive
  
• .. less-detailed but perhaps more digestible output from cargo rustc -- -Ztime-passes: https://pastebin.com/raw/McUNKtP2
• .. the underwhelming output of cargo-llvm-lines, which tells which functions are largest and have the most copies, but in glam's case no functions have more than 1 copy so it mostly tells that (sse2::Mat4 and f64::DMat4)::inverse_checked<true / false> are by far the largest functions, which is probably unavoidable and probably not that impactful overall.
• Edit: there is also crox, but it produces a ~900 MB json file and needs to be opened in Chrome debugger (instructions behind link) so I can't attach that.

I'm no expert here so I can only draw the obvious conclusions that wow, borrowchecking and typechecking are taking a really long time! Which kind of sounds like it is indeed just because there's a lot of code, but maybe someone else would know more.
Macro expansion & CTFE (I was a bit worried about the const assert tests)) don't seem to be culprits, at least.

[bitshifter]

It is surprising, there's very little borrowing going on!

[CatCode79]

Could the 'bytemuck' feature be the cause? As far as I know, it handles everything at compile time.

[CatCode79]

One thing I could do is make the integer types opt in, or opt out. Ultraviolet made f64 and int types opt in (I don't think they added all of the int types that glam has).

I would personally appreciate this feature. I mainly use glam for f32 types, and occasionally for u16 as well—though the latter are just simple structures for modeling screen and texture resolutions, nothing too complex.

[bitshifter]

I added a feature to turn off f64 which took my build time down from about 4s to 3.45s so that would suggest this is probably the way to go to claw back built times for things you don't use. It might take a while to get it all done and it will be a breaking change.