-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It makes startup time significantly longer on Mac #733
Comments
Rust doesn't have life-before-main. Is this dynamic linking perhaps? Is using May I question why 7.6ms start-up is not good enough? That's still good enough for an interactive application, and if you are continually starting your app within a loop, then you know where to start optimising... |
While Rust itself does not, the shared libraries may bring in their own. Either way this seems like an issue that should be reported to Apple, not here. |
Just running otool is slow on OSX, so maybe this comes from dynamic linker overhead, which afaik OSX does rather differently form Linux. Avoid the spawns or play with your build options? |
This issue may be fixed in rust-random/getrandom#38. |
Testing environment:
Reproduce steps:
cargo new hello
rand = "0.6"
into dependencies.main.rs
cargo build --release
The
extern crate rand
line makes the running time ~5x slower (measured by hyperfine):It looks like most of the time is spent on pre-main stuff:
I tried the same steps on a Linux machine, and there is no issue (always ~1ms). Judged by the above information, I guess the culprit is
rand/rand_os/src/macos.rs
Lines 27 to 31 in 731f3d7
It currently blocks me to use rand and some crates that depends on it in a time sensitive application. How can we fix this? Is it ok to use
/dev/urandom
as the platform source on Mac just like what we did for Linux, instead of linking Security.framework?The text was updated successfully, but these errors were encountered: