Rewrite rustc_span::symbol::Interner to avoid double hashing

[heinwol]

Involves resorting to raw HashTable and writing an ad-hoc IndexMap-like structure, as we cannot get access to raw hashes otherwise.

My local cachegrind profile shows ~ -20_000_000 Ir

r? @petrochenkov

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[petrochenkov]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: e66b004 (e66b0048988e203053f928d27053451bfb56886a, parent: 4804ad7e93e1b31f4605b7083871d0d3d85a2afe)

[rust-timer]

Finished benchmarking commit (e66b004): 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
@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.8%	[0.2%, 1.5%]	5
Improvements ✅ (primary)	-0.6%	[-0.8%, -0.2%]	6
Improvements ✅ (secondary)	-0.4%	[-2.1%, -0.0%]	36
All ❌✅ (primary)	-0.6%	[-0.8%, -0.2%]	6

Max RSS (memory usage)

Results (primary 1.6%, secondary 1.2%)

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

	mean	range	count
Regressions ❌ (primary)	1.6%	[1.2%, 2.2%]	4
Regressions ❌ (secondary)	4.0%	[1.1%, 10.0%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-8.1%, -0.6%]	7
All ❌✅ (primary)	1.6%	[1.2%, 2.2%]	4

Cycles

Results (secondary -2.7%)

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.9%	[1.9%, 1.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.4%	[-6.3%, -1.6%]	7
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 509.892s -> 512.954s (0.60%)
Artifact size: 400.78 MiB -> 400.82 MiB (0.01%)

[petrochenkov]

The red numbers in include-blob are a noise from LLVM codegen.

[heinwol]

I've added locking enhancements to reduce contention, maybe this will cause some improvement (or maybe the contrary). Of course, this is only relevant in multithreaded benches, i'm not sure if we can reliably test this.

Also, due to my lack of experience, I'd like a more professional look at whether I have some concurrency bugs. I think I've mitigated the TOCTOU and locking order is deterministic. My benches and tests run fine.

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)