use try_fold instead of try_for_each to reduce compile time

[andjo403]

as it was stated in #64572 that the biggest gain was due to less code was generated I tried to reduce the number of functions to inline by using try_fold direct instead of calling try_for_each that calls try_fold.

as there is some gains with using the try_fold function this is maybe a way forward.
when I tried to compile the clap-rs benchmark I get times gains only some % from #64572

there is more function that use eg. fold that calls try_fold that also can be changed but the question is how mush "duplication" that is tolerated in std to give faster compile times

can someone start a perf run?

cc @nnethercote@scottmcm@bluss
r? @ghost

[Centril]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit fc87c00c5b527660779dbcea0fe4291177100616 with merge 4a55e7b6a6a7beddaf5a2f71ee4d06f3a829524e...

[bors]

☀️ Try build successful - checks-azure
Build commit: 4a55e7b6a6a7beddaf5a2f71ee4d06f3a829524e (4a55e7b6a6a7beddaf5a2f71ee4d06f3a829524e)

[rust-timer]

Queued 4a55e7b6a6a7beddaf5a2f71ee4d06f3a829524e with parent 488381c, future comparison URL.

[rust-timer]

Finished benchmarking try commit 4a55e7b6a6a7beddaf5a2f71ee4d06f3a829524e, comparison URL.

[andjo403]

some procent better than only #64600 but still some way to go until the diffs from #64572 .
do not know how god it is to compare the procent changes for all the perf runs but as there is multiple bases for the PRs it is not possible to compare directly.

[nnethercote]

@andjo403: #64600 has now landed. Could you rebase and update the code here? I think only the first commit will be necessary now, and we can get a fair comparison. Thanks.

[andjo403]

@nnethercote rebased and removed the second commit

[nnethercote]

Thanks!

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 8737061 with merge 40a3c41fdfde051926f256564c247e2ce94a667e...

[bluss]

Assuming we are using try_fold etc everywhere, we can still manually desugar to structs implementing FnMut instead of using closures.

Not the best abstraction level, but doesn't it look like we could save one generic item per iterator method then? Where we currently have the check functions.

[bors]

☀️ Try build successful - checks-azure
Build commit: 40a3c41fdfde051926f256564c247e2ce94a667e (40a3c41fdfde051926f256564c247e2ce94a667e)

[bluss]

Thoughts on equality check vs pattern matching here, can it have an effect or none at all?

[andjo403]

made a quick diff in godbolt and there is less code to inline so that is something that I can do
ZN72$LT$example..LoopState$LT$C$C$B$GT$$u20$as$u20$core..cmp..PartialEq$GT$2eq17h37dbcaf2df999e09E is a lot to inline

[scottmcm]

I would hope it has no effect, since LoopState<(),()> is an i1 in LLVM...

...and it is in -O, but very different in debug: https://rust.godbolt.org/z/LKOpZ7

Looks like the PartialEq::eq that gets generated is pretty bad, and it's still bad removing the generics: https://rust.godbolt.org/z/o6Nuaw Could there be a "this is a field-less enum so just compare the discriminants" path in the derive? It looks, unfortunately, like as u8 == 1 is the shortest-emitted-IR way to do these checks. And we're avoiding the derives in other places too, like

rust/src/libcore/cmp.rs

Lines 632 to 638 in 702b45e

	#[stable(feature = "rust1", since = "1.0.0")]
	implOrdforOrdering{
	#[inline]
	fncmp(&self,other:&Ordering) -> Ordering{
	(*selfasi32).cmp(&(*other asi32))
	}
	}

[bluss]

Oh interesting. So we could improve here just by implementing PartialEq manually, or even adding a separate method for just discriminant comparison. But then pattern matching works well too. Like, just a method for ".is_continue()"

[andjo403]

but the pattern match avoids having a function to inline completely as long as a function is used the llvm-ir will contain a call and a function

[nnethercote]

My rust-timer command above didn't work. Let's try doing it a different way:

@rust-timer build 40a3c41fdfde051926f256564c247e2ce94a667e

[rust-timer]

Queued 40a3c41fdfde051926f256564c247e2ce94a667e with parent 42ec683, future comparison URL.

[andjo403]

Assuming we are using try_fold etc everywhere, we can still manually desugar to structs implementing FnMut instead of using closures.
Not the best abstraction level, but doesn't it look like we could save one generic item per iterator method then? Where we currently have the check functions.

I do not understand can you show some example?

[bluss]

@andjo403 I have an example of a before-after change like that, that I made as PoC. Rust -Zprint-mono-items=lazy tells me this uses 1 less generic function (Before we use check<T> and the closure in the check body, after we use only Fun::call_mut (call_once is never used).) Regrettably it's from a smaller similar iterator, not the exact code in libcore.

Code here https://gist.github.com/b94c565bc5ba37206112c150b8b1cc20

It doesn't look great - maybe a macro could improve that? In fact the code looks so bad, I'm unsure we'd want to do that. 🙂

[andjo403]

thanks @bluss for the example and yes that code was hard to understand

[bluss]

It is equivalent to desugaring the original closure, without the "check(f) hack", but also without capturing extraneous type parameters. So a regular closure would be the same, when #46477 is fixed.

[rust-timer]

Finished benchmarking try commit 40a3c41fdfde051926f256564c247e2ce94a667e, comparison URL.

[Mark-Simulacrum]

Crazy bots! I think I know what's wrong though, will try and fix in a bit, and silence bot for now.

[rust-timer]

Finished benchmarking try commit 40a3c41fdfde051926f256564c247e2ce94a667e, comparison URL.

[nnethercote]

The results are good: up to 7.5% win for clap, and lots of sub-1% wins. Really good for such a simple change!

[scottmcm]

I'm happy with this as-is (we can explore other things like #64885 (comment) in a follow-up PR), so

@bors r+

[bors]

📌 Commit 8737061 has been approved by scottmcm