[perf experiment] Split the resolver tables into per-owner tables

[oli-obk]

r? @ghost

Basically necessary for #138705 as that can't be landed perf-wise (1% primary, 2% secondary regressions) while the hir_crate query is still a thing.

My goal is to split the resolver tables into per-owner tables, so that all information that ast lowering needs from the resolver is separated by owners. This should allow us to fully split ast lowering to have one query invocation per owner that steal the individual resolver results for each owner.

Alternatively we keep the entire resolver state around until hir_crate_items has run and steal and drop it then.

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 33f5615 with merge 792af13...

[bors]

☀️ Try build successful - checks-actions
Build commit: 792af13 (792af13061770b940e351039beebe10bd97d4627)

[rust-timer]

Finished benchmarking commit (792af13): comparison URL.

Overall result: ❌ regressions - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.6%]	129
Regressions ❌ (secondary)	0.5%	[0.1%, 1.5%]	69
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.1%, 0.6%]	129

Max RSS (memory usage)

Results (primary 1.3%, secondary 0.5%)

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.3%	[0.9%, 1.7%]	5
Regressions ❌ (secondary)	1.8%	[1.0%, 2.8%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.4%, -1.6%]	2
All ❌✅ (primary)	1.3%	[0.9%, 1.7%]	5

Cycles

Results (secondary 1.5%)

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)	2.2%	[1.5%, 2.6%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.7%, -1.2%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 777.548s -> 776.554s (-0.13%)
Artifact size: 365.81 MiB -> 365.80 MiB (-0.01%)

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit a16a6f1 with merge 66f172c...

[bors]

☀️ Try build successful - checks-actions
Build commit: 66f172c (66f172c845b537c43e7e41f92eaf99957253f6bd)

[rust-timer]

Finished benchmarking commit (66f172c): comparison URL.

Overall result: ❌ regressions - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.8%]	29
Regressions ❌ (secondary)	0.8%	[0.3%, 2.1%]	30
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	2
All ❌✅ (primary)	0.3%	[0.1%, 0.8%]	29

Max RSS (memory usage)

Results (primary 1.6%, secondary 2.7%)

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.6%	[1.0%, 2.1%]	5
Regressions ❌ (secondary)	3.9%	[2.0%, 7.4%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.3%, -1.1%]	2
All ❌✅ (primary)	1.6%	[1.0%, 2.1%]	5

Cycles

Results (secondary 2.9%)

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)	2.9%	[2.0%, 3.6%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 778.99s -> 777.791s (-0.15%)
Artifact size: 365.92 MiB -> 365.97 MiB (0.01%)

[oli-obk]

ok... better, but not great yet either

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit a78e1a6 with merge 012f3ee...

[bors]

☀️ Try build successful - checks-actions
Build commit: 012f3ee (012f3eec5acc351e2cb934444de98793bf94c9e7)

[bors]

☀️ Try build successful - checks-actions
Build commit: e12315f (e12315ff9ca69d11e40517822568c2a9aafe11ec)

[rust-timer]

Finished benchmarking commit (e12315f): comparison URL.

Overall result: ❌ regressions - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.7%]	10
Regressions ❌ (secondary)	0.8%	[0.2%, 1.9%]	29
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.2%, 0.7%]	10

Max RSS (memory usage)

Results (primary 0.0%, secondary 1.0%)

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%	[0.5%, 1.3%]	4
Regressions ❌ (secondary)	2.7%	[0.9%, 4.2%]	7
Improvements ✅ (primary)	-1.9%	[-2.2%, -1.5%]	2
Improvements ✅ (secondary)	-2.1%	[-3.9%, -1.0%]	4
All ❌✅ (primary)	0.0%	[-2.2%, 1.3%]	6

Cycles

Results (secondary 2.5%)

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)	2.5%	[1.8%, 3.5%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 781.035s -> 781.132s (0.01%)
Artifact size: 365.98 MiB -> 366.07 MiB (0.02%)

[oli-obk]

Ok, so the regressions are now limited to crates that have bazillions of owners

• 20k use items cause a 10% regression in ast lowering and a 6% regression in expansion/def-collection
• 3k extern items cause a 10% regression in expansion/def-collection
• realistic examples like typenum show a 2% regression in expansion/def-collection

[bors]

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

[cjgillot]

In the same idea, two questions:

• should we use compound indices instead of a single u32 for NodeId, like a pair (current item's def-id, node-id inside it) ;
• should we split according to modules or item-like, which act as complete and partial (respectively) resolver barriers.

[oli-obk]

• should we split according to modules or item-like, which act as complete and partial (respectively) resolver barriers.

if we're doing any split, I think I'd prefer to use the same split that HIR uses, so per owner.

• should we use compound indices instead of a single u32 for NodeId, like a pair (current item's def-id, node-id inside it) ;

I would like this, but I'm fairly certain it will cause perf problems due to hash table accesses being slightly more expensive. It would allow making many hash table accesses be per-item index vecs so maybe it'll pay out. or we take the (likely small) perf hit

[oli-obk]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 225d1a5 (225d1a556f2e27fd6abb9e08f50e50bcac7383ff, parent: 7ad4e69ad585d8ff214f7b42d01f1959eda08f40)

[rust-timer]

Finished benchmarking commit (225d1a5): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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.3%	[0.1%, 0.7%]	43
Regressions ❌ (secondary)	0.7%	[0.1%, 2.2%]	39
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.3%	[-0.5%, -0.2%]	8
All ❌✅ (primary)	0.3%	[0.1%, 0.7%]	43

Max RSS (memory usage)

Results (primary 0.8%, secondary 4.1%)

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

	mean	range	count
Regressions ❌ (primary)	1.2%	[0.7%, 2.3%]	7
Regressions ❌ (secondary)	4.9%	[1.2%, 8.8%]	11
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-4.4%	[-4.4%, -4.4%]	1
All ❌✅ (primary)	0.8%	[-2.1%, 2.3%]	8

Cycles

Results (primary 3.0%, secondary 7.1%)

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

	mean	range	count
Regressions ❌ (primary)	3.0%	[2.1%, 3.9%]	2
Regressions ❌ (secondary)	8.0%	[3.2%, 16.9%]	12
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.8%	[-3.8%, -3.8%]	1
All ❌✅ (primary)	3.0%	[2.1%, 3.9%]	2

Binary size

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

Bootstrap: 480.915s -> 482.851s (0.40%)
Artifact size: 398.15 MiB -> 398.16 MiB (0.00%)

[rust-bors]

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