Fix visible_parent_map fallback map merging perf regression

[zalanlevai]

This PR attempts to fix the visible_parent_map perf regression introduced in #160464.

Because the original PR fixes unnecessary iterations in the breadth-first search (BFS), meaning that it only reduces the amount of work during the BFS, the likely cause of the perf regression is the changed merging of the fallback map into the final visible parent map.

The goal of this draft PR is to determine whether this is the case through a perf try run. The change itself works around the Unord* APIs, but might be worth it to work around the perf regression.

• I did not use an LLM to create a change in this PR.
• I used an LLM to create a change in this PR, and I have explained below how it was used.

[JonathanBrouwer]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 9cbccc7 (9cbccc762cb6f14132feb088e9dd05ce77b54760)
Base parent: 153ecc4 (153ecc4f74035b709bb3e1eb9546f1d934865042)

[rust-timer]

Finished benchmarking commit (9cbccc7): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.4%	[0.2%, 0.5%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.5%, -0.4%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -9.2%, secondary -0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.6%	[0.5%, 0.8%]	5
Improvements ✅ (primary)	-9.2%	[-9.2%, -9.2%]	1
Improvements ✅ (secondary)	-0.8%	[-2.4%, -0.4%]	10
All ❌✅ (primary)	-9.2%	[-9.2%, -9.2%]	1

Cycles

Results (secondary 0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.2%	[0.4%, 5.0%]	11
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.7%	[-1.6%, -0.4%]	11
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 458.036s -> 460.145s (0.46%)
Artifact size: 398.61 MiB -> 398.66 MiB (0.01%)

[zalanlevai]

@JonathanBrouwer Thanks! I had a look through the perf run results and compared each benchmark that regressed in #160464 with the corresponding benchmark in this perf run. This change resolves all 7 perf regressions introduced in #160464, with the percentage deltas in this perf run cancelling out the ones in the perf run of the regressed PR.

This change's perf run also shows 7 other perf regressions of similar magnitude: 5 are the deep-vector benchmark and the other two are the tuple-stress benchmark. However, looking at their code, these two benchmarks do not contain code that would be affected by this change, at least from what I can tell. Looking at the profiles for these regressed benchmarks, the visible_parent_map query is not significant enough to show up in any of the before or after profiles. Do you think these new regressions could be a fluke or unrelated to this change?

[zalanlevai]

I believe this is the correct label given the findings in my previous comment.

@rustbot label +perf-regression-triaged