-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
The compiler with debug assertions is really slow #121110
Comments
This is probably because of the recent changes to |
Add `#[rustc_no_mir_inline]` for standard library UB checks should help with rust-lang#121110 and also with rust-lang#120848 I am not entirely sure whether this is the correct solution and I haven't validated it, I just quickly threw it together before going to sleep. r? `@saethlin`
…aethlin Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (rust-lang#121112)): 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` rust-lang#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)! r? `@saethlin` (or anyone else if someone wants to review this) fixes rust-lang#121110, supposedly
…aethlin Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (rust-lang#121112)): 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` rust-lang#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)! r? ``@saethlin`` (or anyone else if someone wants to review this) fixes rust-lang#121110, supposedly
Rollup merge of rust-lang#121196 - Nilstrieb:the-clever-solution, r=saethlin Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (rust-lang#121112)): 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` rust-lang#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)! r? ```@saethlin``` (or anyone else if someone wants to review this) fixes rust-lang#121110, supposedly
turns out this was caused by many different factors compounding in an unfortunate way :D |
Add `#[rustc_no_mir_inline]` for standard library UB checks should help with rust-lang#121110 and also with rust-lang#120848 I am not entirely sure whether this is the correct solution and I haven't validated it, I just quickly threw it together before going to sleep. r? `@saethlin`
Add `#[rustc_no_mir_inline]` for standard library UB checks should help with rust-lang#121110 and also with rust-lang#120848 Because the MIR inliner cannot know whether the checks are enabled or not, so inlining is an unnecessary compile time pessimization when debug assertions are disabled. LLVM knows whether they are enabled or not, so it can optimize accordingly without wasting time. r? `@saethlin`
The compiler compiled with debug assertions has gotten really slow recently. For example, compiling the standard library takes way longer than it used to.
This is bad, it makes it way harder to work on rustc.
The text was updated successfully, but these errors were encountered: