Improve get_by_key_enumerated more

[JohnTitor]

Follow-up of #86392, this applies the suggestions by @m-ou-se.

r? @m-ou-se

[rust-timer]

Finished benchmarking try commit (172d0d098473f7e9b4ee053d7ed424405c064d3a): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[m-ou-se]

This still requires finding the upper bound/amount of items before returning the iterator. That's needed because the key (of type &Q) doesn't live long enough to return it. But since get_by_key_enumerated is only ever used by get_by_key, and get_by_key is only ever used with K = Symbol (which is Copy and even smaller than a reference), maybe it's best to remove the Q type, and just take a K by value. Then you can return the .take_while() iterator directly, without .count()'ing it.

[JohnTitor]

So, you mean making SortedIndexMultiMap Symbol-specific? If so, wouldn't it need us to move out SortedIndexMultiMap to somewhere?

[m-ou-se]

No, I'm suggesting just taking the K by value, instead of borrowing a Q. Then you can just move it into the closure, and return the .take_while() directly.

[JohnTitor]

Ah, that makes sense! Applied the suggestion via d731d61.

[rust-timer]

Finished benchmarking try commit (a683ef3cff6fb2682ca8fbed8aa293340539643d): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[m-ou-se]

Nice.

(You still need to update the tests.)

Since I'm not on the compiler team or compiler-contributors, assigning it to someone on the compiler team for final approval:

r? @matthewjasper

[bors]

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

[JohnTitor]

r? @oli-obk for re-assigning (according to the GitHub reviewer suggestions)

[oli-obk]

@bors r+

[bors]

📌 Commit 6761826 has been approved by oli-obk

[bors]

⌛ Testing commit 6761826 with merge 3b4a0df...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 3b4a0df to master...