Skip to content

Add #[inline] to Either::fold - #147

Merged
cuviper merged 1 commit into
rayon-rs:mainfrom
joshtriplett:either-fold-inline
Oct 6, 2026
Merged

cuviper merged 1 commit into
rayon-rs:mainfrom
joshtriplett:either-fold-inline

Conversation

@joshtriplett

Copy link
Copy Markdown
Contributor

This provided a non-trivial performance improvement when I was doing
some compiler performance work, saving 1.5M instructions on some hot
paths that were using Either for an iterator.

@cuviper

cuviper commented Oct 5, 2026

Copy link
Copy Markdown
Member

I'm surprised this is needed -- this is a generic function so it should get local codegen, and it's small enough that I would even expect the MIR inliner to process it proactively. Do you have any analysis why that's not happening?

If we need this one, we should probably inline all iterator methods, but I'd like to understand why.

@joshtriplett

Copy link
Copy Markdown
Contributor Author

I don't have an analysis of why it wasn't happening, just that it wasn't happening. In the code I was building (part of rust-lang/rust#163744 ), Either::fold ended up being out-of-line in a hot path, and inlining it helped. (I ended up working around it by open-coding some callers instead, which worked, but seemed unfortunate.)

rust-lang/rust#163775 is an example of a similar, sizable win provided by inlining methods that seem like they should be simple enough to not need the hint.

I don't know if inlining every method is the right answer, but it does seem likely that inlining all the simple ones might be.

@cuviper

cuviper commented Oct 5, 2026

Copy link
Copy Markdown
Member

I don't know if inlining every method is the right answer, but it does seem likely that inlining all the simple ones might be.

Well, the methods are all equally simple here, merely dispatching to the inner variant.

@joshtriplett

joshtriplett commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor Author

I think one reason the fold functions show up more heavily in profiles, and sometimes aren't inlined, is because of the logic around its closure. But there's no reason not to add the #[inline] annotations to the rest; they're just more in the category of "compiler will probably get them right without the annotation".

Want me to rework this to add the annotations to everything? (fold is the one I actually saw show up in profiles; I don't have any data for the rest.)

@cuviper

cuviper commented Oct 6, 2026

Copy link
Copy Markdown
Member

Let's at least be consistent with fold and rfold, and on IterEither too.

This provided a non-trivial performance improvement when I was doing
some compiler performance work, saving 1.5M instructions on some hot
paths that were using Either for an iterator.
@joshtriplett

Copy link
Copy Markdown
Contributor Author

@cuviper Done.

@cuviper

cuviper commented Oct 6, 2026

Copy link
Copy Markdown
Member

Thanks!

@cuviper
cuviper added this pull request to the merge queue Oct 6, 2026
Merged via the queue into rayon-rs:main with commit 44a0670 Oct 6, 2026
10 checks passed
@joshtriplett
joshtriplett deleted the either-fold-inline branch October 7, 2026 05:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants