Optimize notable_trait_buttons

[yotamofek]

Small cleanup.
Use Iterator::any instead of for loop with predicate = true;.
I think this makes the code more readable... and also has the additional benefit of short-circuiting the iterator when a notable trait is found (a break statement was missing in the for loop version, I think). Probably won't be significant enough to show on perf results, though.

Three commits, each attempting to optimize notable_trait_buttons by a little bit.

[rustbot]

r? @GuillaumeGomez

rustbot has assigned @GuillaumeGomez.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[yotamofek]

(speculating out loud to no one in particular)
Is there any reason why Context::types_with_notable_traits is an IndexSet instead of a HashSet?
Only time it's ever iterated over is in notable_traits_json, where it's immediately sorted, so I don't see the value of preserving insertion order with IndexSet. HashMap should be a little faster and smaller in memory footprint.

[GuillaumeGomez]

I think it might have an impact on performance, we'll see. I'll run a perf check once suggestion has been applied.

I personally tend to prefer for loops but I don't see a reason not to switch to iterator combinators here.

[yotamofek]

I personally tend to prefer for loops but I don't see a reason not to switch to iterator combinators here.

It's a matter of style and personal preference, I guess. I'm the opposite - I usually prefer "functional" style. Especially with stuff like .any(), like in this case. I think it makes the purpose of the loop clearer, i.e. this loop is looking for at least one case of element-that-satisfies-some-predicate.
But yeah, just a matter of taste. :)

[GuillaumeGomez]

Personal taste and stuff. I see improvement, personal taste comes second. 😉

Let's check perf.

@bors try @rust-timer queue

[bors]

⌛ Trying commit fee4729 with merge b30f3e7...

[yotamofek]

Oh BTW, if we're talking perf,
if we're already populating a cache of types_with_notable_traits here, couldn't we just check if a type is already there first?

[GuillaumeGomez]

Sounds like a great idea!

[yotamofek]

Ok, added another commit with that.
And just noticed that when I (manually) applied your suggestion earlier, I accidentally left the old .filter() in. 😓
I guess most chances are the compiler will be smart enough to not perform the if twice, but if not then it might skew the perf run.

[yotamofek]

@GuillaumeGomez rustc-perf hasn't noticed the try build finished (again),
but in the meanwhile I added a 3rd commit changing the FxIndexSet into a FxHashSet.
In local perf runs, none of the 3 commits showed any improvements. We can try to see if it makes any difference on CI, but if it stays neutral then maybe this PR can just be closed.

[aDotInTheVoid]

This is technically ok, as notable_traits_json sorts the items, but just looking at this code, that's not clear why.

Given that this is the only callsite, it'd be better to pass a FxHashMap (instead of an opaque impl Iterator, so the allow can be next to a comment explaining why it's ok. That way all that reasoning about why this is correct stays local.

[yotamofek]

I agree, fixed.
(I used the #[expect] attribute because it's cool and I hadn't had a chance to use it yet, not sure if it should just be #[allow])

[GuillaumeGomez]

I wonder if it's because you pushed? Well, try not to push before this one runs then. ;)

@bors try @rust-timer queue

[bors]

⌛ Trying commit afdf48d with merge 613e9cd...

[bors]

☀️ Try build successful - checks-actions
Build commit: 613e9cd (613e9cd968ec0f2cc5541e9d3c9eb9bfb8d739a7)

[rust-timer]

Finished benchmarking commit (613e9cd): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -0.9%, secondary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	6.3%	[6.3%, 6.3%]	1
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-7.0%	[-7.0%, -7.0%]	1
All ❌✅ (primary)	-0.9%	[-2.8%, 1.0%]	2

Cycles

Results (primary -14.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-14.4%	[-19.0%, -11.1%]	13
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-14.4%	[-19.0%, -11.1%]	13

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 787s -> 785.515s (-0.19%)
Artifact size: 348.27 MiB -> 348.30 MiB (0.01%)

[bors]

☔ The latest upstream changes (presumably #136828) made this pull request unmergeable. Please resolve the merge conflicts.

[yotamofek]

Woops, wrong button

[aDotInTheVoid]

We can try to see if it makes any difference on CI, but if it stays neutral then maybe this PR can just be closed.

Do you think this is worth merging given the perf results?

[yotamofek]

I think 0da8b61 is beneficial even with no improvements to perf, it makes the code more readable (IMHO) and a bit more correct (because it short-circuits when it finds a notable trait impl).
The second commit just makes the code messier, and the third commit I'm ambivalent about.
So whatever you think is fine by me 😊

[bors]

☔ The latest upstream changes (presumably #137425) made this pull request unmergeable. Please resolve the merge conflicts.