Uh oh!
There was an error while loading. Please reload this page.
pub async fn impl is monomorphized when func itself is monomorphized - #143290
Conversation
rustbot
commented
Jul 1, 2025
oli-obk
commented
Jul 2, 2025
I don't think this needs a -Z flag. It makes a lot of sense to just change this everywhere. We can then benchmark it in the benchmark suite, too. A similar change could be done for iterator or closure returning functions. On that note: instead of collecting nested bodies in general, wouldn't it be slightly more correct to collect types that are in the opaque (non-opque types must already have all their impls monomorphized, as they are publicly reachable) return type of monomorphized functions? For opaque types we'd only need to monomorphize the trait impls that the opaque type has in its bounds cc @compiler-errors for thoughts as you wrote #135314 |
d6bb74b to
a6b81d5Comparerustbot
commented
Jul 2, 2025
Some changes occurred in coverage tests. cc @Zalathar |
a6b81d5 to
d6e2c24Compareazhogin
commented
Jul 2, 2025
Flag removed, behaviour changed to be default. |
This comment has been minimized.
This comment has been minimized.
oli-obk
commented
Jul 2, 2025
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
bors
commented
Jul 2, 2025
pub async fn impl is monomorphized when func itself is monomorphized
Implentation coroutine (`func::{closure#0}`) is monomorphized, when func itself is monomorphized.
Currently, when `pub async fn foo(..)` is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation, `func::{closure#0}` will be monomorphized in every dependency.
This PR adds monomorphization for `func::{closure#0}` (coroutine poll function), when func itself is monomorphized.
Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).bors
commented
Jul 2, 2025
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
rust-timer
commented
Jul 3, 2025
Finished benchmarking commit (9443527): comparison URL. Overall result: ❌ regressions - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -3.1%, secondary 2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.5%, secondary 4.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary 9.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 462.08s -> 462.853s (0.17%) |
oli-obk
commented
Jul 4, 2025
Some tests need blessing The performance regression is expected, as the regressing benchmark has public |
Zalathar
commented
Jul 6, 2025
In particular, you will need to set |
d6e2c24 to
57c2602Compare
This comment has been minimized.
This comment has been minimized.
azhogin
commented
Jul 8, 2025
It looks like '-Z print-type-sizes' shows different results for x86_64 and aarch64 for some tests. Are there some helpfull flags to remove the difference between targets (except Also, I performed |
oli-obk
commented
Jul 9, 2025
you could limit the test to one platform with |
57c2602 to
e6b35f4Comparebors
commented
Jul 22, 2025
☔ The latest upstream changes (presumably #144249) made this pull request unmergeable. Please resolve the merge conflicts. |
oli-obk
commented
Jul 23, 2025
oh sorry I didn't realize you addressed this. @bors delegate+ r=me after a rebase |
97b9fc4 to
961e96aCompareazhogin
commented
Aug 31, 2025
@bors r=oli-obk |
bors
commented
Aug 31, 2025
pub async fn impl is monomorphized when func itself is monomorphized
Implentation coroutine (`func::{closure#0}`) is monomorphized, when func itself is monomorphized.
Currently, when `pub async fn foo(..)` is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation, `func::{closure#0}` will be monomorphized in every dependency.
This PR adds monomorphization for `func::{closure#0}` (coroutine poll function), when func itself is monomorphized.
Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).bors
commented
Aug 31, 2025
This comment has been minimized.
This comment has been minimized.
bors
commented
Aug 31, 2025
💔 Test failed - checks-actions |
…hized, when func itself is monomorphized
961e96a to
c2c58cbCompareazhogin
commented
Sep 1, 2025
@bors r=oli-obk |
bors
commented
Sep 1, 2025
bors
commented
Sep 1, 2025
bors
commented
Sep 1, 2025
☀️ Test successful - checks-actions |
Uh oh!
There was an error while loading. Please reload this page.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 84a1747 (parent) -> c0bb3b9 (this PR) Test differencesShow 13 test diffsStage 1
Stage 2
Additionally, 2 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard c0bb3b98bb7aac24a37635e5d36d961e0b14f435 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
rust-timer
commented
Sep 1, 2025
Finished benchmarking commit (c0bb3b9): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary 4.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 4.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary 9.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 468.417s -> 466.41s (-0.43%) |
Kobzol
commented
Sep 2, 2025
The regression is expected, as we now do more work for async fns in their crate, with the hope of reducing the amount of work required in downstream crates. @rustbot label: +perf-regression-triaged |
Implentation coroutine (
func::{closure#0}) is monomorphized, when func itself is monomorphized.Currently, when
pub async fn foo(..)is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation,func::{closure#0}will be monomorphized in every dependency.This PR adds monomorphization for
func::{closure#0}(coroutine poll function), when func itself is monomorphized.Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).