pub async fn impl is monomorphized when func itself is monomorphized #143290
+138
−15
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
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 |
azhogin
force-pushed
the
azhogin/link-pub-async-impls
branch
from
d6bb74b to
a6b81d5
Compare
|
Some changes occurred in coverage tests. cc @Zalathar |
azhogin
force-pushed
the
azhogin/link-pub-async-impls
branch
from
a6b81d5 to
d6e2c24
Compare
azhogin
changed the title
|
Flag removed, behaviour changed to be default. |
This comment has been minimized.
This comment has been minimized.
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
bors
added a commit
that referenced
this pull request
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).
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
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%) |
rustbot
added
perf-regression
|
Some tests need blessing The performance regression is expected, as the regressing benchmark has public |
|
In particular, you will need to set |
…hized, when func itself is monomorphized
azhogin
force-pushed
the
azhogin/link-pub-async-impls
branch
from
d6e2c24 to
57c2602
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).