perf(semantic): use swap_remove instead of into_iter().next() in into_root

[camc314]

No description provided.

[camc314]

• perf(semantic): use match_module_declaration! macro instead of match guard #17184
• perf(semantic): use swap_remove instead of into_iter().next() in into_root #17183 👈 (View in Graphite)
• perf(semantic): use split_at_mut instead of iterator in current_and_parent_mut #17182
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

CodSpeed Performance Report

Merging #17183 will not alter performance

_{Comparing c/12-20-perf_semantic_use_swap_remove_instead_of_into_iter_.next_in_into_root (ff2620d) with c/12-20-perf_semantic_use_split_at_mut_instead_of_iterator_in_current_and_parent_mut (18ed7de)}

Summary

✅ 42 untouched
⏩ 3 skipped¹

Footnotes

1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[camc314]

This is only called 1x so probably no meaningful perf difference

[overlookmotel]

I'm very surprised this is any more performant. Creating a slice iterator is extremely cheap (like 1 operation), and in this case even that 1 op should be removed due to the unchecked assertion.

swap_remove is a more complex operation.

What makes you think this is faster? Do you have a demonstration that it is?

Maybe something has changed with the effectiveness of unchecked assertions. If so it'd be good to find out!

[camc314]

I'm very surprised this is any more performant. Creating a slice iterator is extremely cheap (like 1 operation), and in this case even that 1 op should be removed due to the unchecked assertion.

swap_remove is a more complex operation.

What makes you think this is faster? Do you have a demonstration that it is?

Maybe something has changed with the effectiveness of unchecked assertions. If so it'd be good to find out!

I fear something has changed in more recent rust versions, because that's not the behaviour I see:

https://godbolt.org/z/zrs81Gbns

using swap_remove is ~57 lines of assembluy (no panic calls), whereas the previous is ~141 and a panic call.

For the iterator case, the assert_unchecked assertion doesn't seem to do anything

[graphite-app]

Merge activity

• Dec 22, 1:44 PM UTC: Boshen added this pull request to the Graphite merge queue.
• Dec 22, 1:57 PM UTC: Merged by the Graphite merge queue.