-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Inconsistent inlineing of Iterator Adaptors - Missed Optimizations #47461
Comments
Note that all iterator adaptors are generic and therefore instantiated in the crate using them, making them available for inlining in principle. Adding We should still be consistent about how we use |
Is there an improvement in the generated instructions if you annotate |
@varkor I do not have a minimal example or a good testcase where I could compare the assembly. I just noticed that in profiling the @rkruppe You make a good point. I forgot that generic functions are always inlineable. I got fooled by the results. |
I had no deep logic for marking or not marking try_fold methods with @jonasbb I see "anymore" in your comment. Did the behaviour here change in a recent nightly? |
@scottmcm No, it is unrelated to nightly changes. For other reasons I already have xargo setup and just played around with adding inline annotation and reprofiling. |
I can confirm that I have this issue on Although I failed to create a MRE I can provide function source code and assembly that gets generated if needed. I suspect it has to deal something with inlining budget or some werights but I'm pretty sure I don't want to have iterators in resulting release assembly. |
While profiling some rust code of me, I noticed that the following pattern does not optimize well:
skip_while
is implemented usingfind
andfind
is implemented usingtry_fold
. The functionsSkipWhile::next()
andIterator::find()
use the#[inline]
annotation. The functionMap::try_fold()
does not. This means thatMap::try_fold()
will not be inlined.I started looking at the source code and inlineing of iterators seems to follow no rule. I could not find any bug reports related to this.
Filter::try_fold
is inlineEnumerate::try_fold
is inlineRev::try_fold
is not inlineSome iterators like
Cloned
do not have any function marked as inline. Not evennext()
is marked as inline.The PR introducing
try_fold
does not give justification why sometry_fold
s are inline and some are not.The methods
len
andis_empty
ofExactSizeIterator
's are also not marked as inlineable, even though they are always implemented as pass-through to the underlying iterator.If desired I can prepare a pull request to mark those functions as inlineable. Is there a list of functions for the iterator traits (e.g., Iterator, ExactSizeIterator) which should be inline/not be inline?
The text was updated successfully, but these errors were encountered: