[GH-ISSUE #1220] Compilation cycle is slow #434

New issue

Closed

opened 2026-02-27 08:17:17 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 08:17:17 +03:00

Owner

Originally created by @selfhoster1312 on GitHub (Jul 17, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1220

Simply rebuilding the lldap binary in release mode takes >2m on my machine (without dependent crates).

It's not even a slow machine!

I see there's opt flags in Cargo.toml for optimized binary size (opt-level=s) and optimized linking (lto=true), both of which can make compilation slower. I think these are good values for building release tarballs but should not be the default when cloning the repo.

The size-optimized binary (built with nightly in release mode from main branch) is 30MB. Removing those two lines in Cargo.toml produces a binary of 38MB, but takes me 2m30s for the entire build instead of just the lldap crate (which alone now takes 22s).

Building the frontend is not much faster using this config, yielding a 3.9MB wasm blob instead of 3.0MB in 41s total build vs 47s. In this case, i think these optimizations make sense.

I'm used to making release builds even during development. Maybe i should not? Two possibilities:

if you'd like to keep these settings in Cargo.toml i can add dev docs about this
if not, i can make a PR to change the default values, and change the CI scripts to use the current optimization values

Originally created by @selfhoster1312 on GitHub (Jul 17, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1220 Simply rebuilding the lldap binary in release mode takes >2m on my machine (without dependent crates). <img width="497" height="512" alt="Image" src="https://github.com/user-attachments/assets/032dbf09-6752-4fbd-a53f-1cfe1304b558" /> It's not even a slow machine! I see there's opt flags in Cargo.toml for optimized binary size (opt-level=s) and optimized linking (lto=true), both of which can make compilation slower. I think these are good values for building release tarballs but should not be the default when cloning the repo. The size-optimized binary (built with nightly in release mode from main branch) is 30MB. Removing those two lines in Cargo.toml produces a binary of 38MB, but takes me 2m30s for the *entire* build instead of just the lldap crate (which alone now takes 22s). Building the frontend is not much faster using this config, yielding a 3.9MB wasm blob instead of 3.0MB in 41s total build vs 47s. In this case, i think these optimizations make sense. I'm used to making release builds even during development. Maybe i should not? Two possibilities: - if you'd like to keep these settings in Cargo.toml i can add dev docs about this - if not, i can make a PR to change the default values, and change the CI scripts to use the current optimization values

kerem closed this issue

2026-02-27 08:17:17 +03:00

kerem commented

2026-02-27 08:17:18 +03:00

Author

Owner

@nitnelave commented on GitHub (Jul 17, 2025):

I'm surprised that you're making release builds during development. Debug builds should be the default for dev, and even then most of the time rustc saves you the pain of compiling and cargo check does most of the rest. I basically only ever compile to run the tests or do final checks on the finished PR.

@nitnelave commented on GitHub (Jul 17, 2025): I'm surprised that you're making release builds during development. Debug builds should be the default for dev, and even then most of the time rustc saves you the pain of compiling and cargo check does most of the rest. I basically only ever compile to run the tests or do final checks on the finished PR.

kerem commented

2026-02-27 08:17:18 +03:00

Author

Owner

@nitnelave commented on GitHub (Oct 4, 2025):

I'm not sure there is anything for us to do here: compilation speed is a trade-off with performance of the binary, and it makes sense for release builds to take long to optimize an artifact that will be used in production. Debug is the other side of the tradeoff.

@nitnelave commented on GitHub (Oct 4, 2025): I'm not sure there is anything for us to do here: compilation speed is a trade-off with performance of the binary, and it makes sense for release builds to take long to optimize an artifact that will be used in production. Debug is the other side of the tradeoff.

kerem referenced this issue

2026-02-27 09:09:34 +03:00

[PR #434] [MERGED] Add example for Gitea's simple auth mode #739