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
It is a fairly well known & common problem that the efficiency of the generated in Rust is very low.
We've run into it multiple times where runtime performance becomes impossible to achieve with certain use cases and hot code, where one could get 1/200th of the performance compared to an optimized release build.
A typical such example is cryptographic hashing. Using the sha1 crate on a 10 MB file runs at 1 MB/s in debug compared to 200 MB/s in release, making it effectively unusable for that use case.
A common workaround is to build dev/debug config with O1 instead of O0, and in this specific case it improves performance to around 1/4th of release performance, but at the cost of significantly increasing compile and iteration times instead which we don't want to do for our large project and repository at this time.
There seems to be two potential solutions here, one short term and one longer term.
Short term:
Stabilize and use the new Profile Overrides cargo feature. This is available on nightly and I've tested this to work well for our worst use case so one can enable O3 just on say the sha crate.
[profile.dev.overrides.sha]
opt-level = 3
Longer term:
Fast code iteration and decent debug performance using Cranelift debug backend for Rust. This is a specific goal for Cranelift but likely a lot of work
The text was updated successfully, but these errors were encountered:
You may have interest in tracking this bug: rust-lang/rust#63484
"Using profile-overrides results in both optimized and unoptimized versions of the same crate in linked executable"
Just a heads up, this is supposed to hit stable in 1.41! :) rust-lang/cargo#7591
There is a workaround for the bug I mentioned above that prevented generic code from being optimized (this mattered quite a lot in my case using nalgebra and nphysics)
This issue has seen no activity for 4 years except for removing the high priority label. Is it still relevant? I'm going through these issues because I'm trying to figure out if there's anything I could help with. It seems like some of the issues could be cleaned up a bit to create focus.
It is a fairly well known & common problem that the efficiency of the generated in Rust is very low.
We've run into it multiple times where runtime performance becomes impossible to achieve with certain use cases and hot code, where one could get 1/200th of the performance compared to an optimized release build.
A typical such example is cryptographic hashing. Using the
sha1
crate on a 10 MB file runs at 1 MB/s in debug compared to 200 MB/s in release, making it effectively unusable for that use case.A common workaround is to build dev/debug config with
O1
instead ofO0
, and in this specific case it improves performance to around 1/4th of release performance, but at the cost of significantly increasing compile and iteration times instead which we don't want to do for our large project and repository at this time.There seems to be two potential solutions here, one short term and one longer term.
Short term:
O3
just on say thesha
crate.Longer term:
The text was updated successfully, but these errors were encountered: