search

str4d / rage

A simple, secure and modern file encryption tool (and Rust library) with small explicit keys, no config options, and UNIX-style composability.
https://age-encryption.org/v1
Apache License 2.0
2.69k stars 104 forks source link

Enable Link-Time Optimization (LTO) #534

Open zamazan4ik opened 1 month ago

zamazan4ik commented 1 month ago

Hi!

I noticed that in the Cargo.toml file Link-Time Optimization (LTO) for the project is not enabled. I suggest switching it on since it will reduce the binary size (always a good thing to have) and will likely improve the application's performance a bit.

I suggest enabling LTO only for the Release builds so as not to sacrifice the developers' experience while working on the project since LTO consumes an additional amount of time to finish the compilation routine. If you think that a regular Release build should not be affected by such a change as well, then I suggest adding an additional dist or release-lto profile where additionally to regular release optimizations LTO will also be added. Such a change simplifies life for maintainers and others interested in the project persons who want to build the most performant version of the application. Using ThinLTO should also help to reduce the build-time overhead with LTO. If we enable it on the Cargo profile level, users, who install the application with cargo install, will get the LTO-optimized version "automatically". E.g., check cargo-outdated Release profile.

Basically, it can be enabled with the following lines:

[profile.release]
lto = true

Thank you.

P.S. It's more like an improvement idea rather than a bug. I created the issue just because the Discussions are disabled for the repo for now.

ghost commented 1 month ago

Win 11 "properties" button is showing rage.exe to be 4.02 MB (4,225,024 bytes) and rage-keygen.exe to be 2.94 MB (3,090,944 bytes) -- By modern standards, both file sizes are very acceptable. When you compile in production mode, let it do its thing. It would be hard but could be done-, to prove the benefits of lto = true with benchmarks for each os and hardware specs. While you do bring up a valid point, the point would be stronger with benchmarks or other proof that your implementation would be worth the effort. The downsides (if any) should be fully known and understood before changes are made. If a mode like lto = true was superior in all use cases, the Rust compiler would include it in the production mode that the compiler has.