Create the previous dep graph index on a background thread

[Zoxc]

This changes SerializedDepGraph.index to be computed on-demand per dep kind. This means we can immediately start using queries without waiting for the entire index to be constructed. Additionally a background thread is started which computes the entire index, effectively off-loading most of the index construction to the background thread.

Benchmark	Before	After		Before	After
	Time	Time	%	Memory	Memory	%
🟣 clap:check:unchanged	0.4259s	0.4225s	-0.79%	89.65 MiB	90.08 MiB	0.48%
🟣 hyper:check:unchanged	0.1425s	0.1417s	-0.53%	47.85 MiB	47.91 MiB	0.13%
🟣 regex:check:unchanged	0.3188s	0.3157s	-0.97%	71.09 MiB	71.58 MiB	0.69%
🟣 syn:check:unchanged	0.5895s	0.5813s	💚 -1.38%	101.68 MiB	102.15 MiB	0.47%
🟣 syntex_syntax:check:unchanged	1.4392s	1.4361s	-0.22%	200.62 MiB	201.68 MiB	0.53%
Total	2.9158s	2.8974s	-0.63%	510.89 MiB	513.40 MiB	0.49%
Summary	1.0000s	0.9922s	-0.78%	1 byte	1.00 bytes	0.46%

Benchmark	Before	After		Before	After
	Time	Time	%	Memory	Memory	%
🟠 clap:debug:unchanged	1.0753s	1.0684s	-0.64%	142.80 MiB	142.72 MiB	-0.05%
🟠 hyper:debug:unchanged	0.2857s	0.2847s	-0.35%	63.06 MiB	63.15 MiB	0.13%
🟠 regex:debug:unchanged	0.7703s	0.7633s	-0.90%	108.76 MiB	109.03 MiB	0.25%
🟠 syn:debug:unchanged	1.0596s	1.0531s	-0.62%	142.08 MiB	142.18 MiB	0.07%
🟠 syntex_syntax:debug:unchanged	2.7530s	2.7274s	-0.93%	308.92 MiB	308.63 MiB	-0.09%
Total	5.9438s	5.8969s	-0.79%	765.62 MiB	765.71 MiB	0.01%
Summary	1.0000s	0.9931s	-0.69%	1 byte	1.00 bytes	0.06%

r? @cjgillot

[Mark-Simulacrum]

Shouldn't we block this on a job server token being available for this extra computation work?

[Zoxc]

I'm not sure if that's performance win as it's more efficient if this completes in a timely manner. setup_index is less efficient than doing all the dep kinds at once.

[Mark-Simulacrum]

I'm not sure if that's performance win as it's more efficient if this completes in a timely manner.

I don't really follow. Jobserver token availability isn't about performance, strictly speaking, it's about making sure that we're not consuming more resources than the host has and/or the user is willing to give. We've definitely had complaints about -j1 (for example) not being respected before.

If we don't have a token available, that may mean that we should do the work in-band (i.e., not spawning the thread) even if that is slower. But, that's what's going to happen anyway on a system that's already CPU-saturated - just via kernel scheduling - which is the alternative here, right? So I don't really understand how the token would be a problem.

[Zoxc]

I guess we could add a try_acquire method to the jobserver and only spawn the thread if we get a token. It looks like that would be racy on POSIX though. I'm not sure if macOS or Linux offers a way to do non-blocking reads.

[Zoxc]

I've made the PR check for a free token now. It's a bit racy but probably works fine.

[cjgillot]

In a typical compilation, when happens the first use of this reciprocal index?
I'm tempted to say very early, as the first query to be invoked needs it.
In which cases is this beneficial?

[Zoxc]

In a typical compilation, when happens the first use of this reciprocal index?
I'm tempted to say very early, as the first query to be invoked needs it.

It will end up calling setup_index, which constructs the index for only that query kind. It's beneficial if we don't use too many query kinds (around 23) before the background thread sets them all.

[bors]

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

[wesleywiser]

Hi @cjgillot, I think this is ready for another round of review as all of the discussion threads have replies from @Zoxc. Thanks!

[Zoxc]

Probably should do a perf run here as the result in #122070 was more mixed than expected.

[cjgillot]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 1b9f6d8 with merge fa1beb3...

[bors]

☀️ Try build successful - checks-actions
Build commit: fa1beb3 (fa1beb3d6a488d654692efb29b4b14c08b15a554)

[bors]

☀️ Try build successful - checks-actions
Build commit: fa1beb3 (fa1beb3d6a488d654692efb29b4b14c08b15a554)

[rust-timer]

Finished benchmarking commit (fa1beb3): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

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 a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.0%	[0.3%, 3.4%]	103
Regressions ❌ (secondary)	1.5%	[0.6%, 2.3%]	27
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[0.3%, 3.4%]	103

Max RSS (memory usage)

Results

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.3%	[1.6%, 3.1%]	3
Improvements ✅ (primary)	-1.1%	[-1.1%, -1.1%]	1
Improvements ✅ (secondary)	-3.3%	[-6.4%, -1.3%]	54
All ❌✅ (primary)	-1.1%	[-1.1%, -1.1%]	1

Cycles

Results

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.7%	[1.0%, 2.4%]	14
Regressions ❌ (secondary)	3.0%	[2.2%, 3.6%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.7%	[1.0%, 2.4%]	14

Binary size

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

Bootstrap: 647.634s -> 647.342s (-0.05%)
Artifact size: 310.02 MiB -> 309.93 MiB (-0.03%)

[Zoxc]

That's quite an odd performance result. It seem to have large wall time regressions which don't show up in the self profiling results nor can I reproduce them locally.

[apiraino]

I think this is waiting on a comment on the perf run? @Zoxc Do you need some directions?
Also a rebase when you have a chance. Thanks!

@rustbot author

[alex-semenyuk]

@Zoxc
Form wg-triage. Any updates on this PR?

[alex-semenyuk]

@Zoxc
From wg-triage. Closed this PR due to inactivity. Feel free to reopen or raised new one. Thanks for your efforts.

[Kobzol]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 6fd274a with merge 6c5d278...

[bors]

☀️ Try build successful - checks-actions
Build commit: 6c5d278 (6c5d2785dca5db9a5260d000070d2fb7188e3d6d)

[rust-timer]

Finished benchmarking commit (6c5d278): 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)	2.4%	[0.3%, 4.1%]	121
Regressions ❌ (secondary)	1.2%	[0.5%, 2.1%]	24
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.3%]	1
All ❌✅ (primary)	2.3%	[-0.2%, 4.1%]	122

Max RSS (memory usage)

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

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.7%	[0.8%, 3.4%]	3
Regressions ❌ (secondary)	5.6%	[5.6%, 5.6%]	1
Improvements ✅ (primary)	-1.9%	[-2.1%, -1.6%]	3
Improvements ✅ (secondary)	-2.5%	[-2.6%, -2.3%]	3
All ❌✅ (primary)	-0.1%	[-2.1%, 3.4%]	6

Cycles

Results (primary 1.4%, secondary -1.4%)

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.4%	[0.6%, 2.2%]	19
Regressions ❌ (secondary)	1.7%	[1.3%, 2.1%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.5%	[-6.3%, -2.8%]	2
All ❌✅ (primary)	1.4%	[0.6%, 2.2%]	19

Binary size

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

Bootstrap: 774.166s -> 776.361s (0.28%)
Artifact size: 365.07 MiB -> 365.07 MiB (0.00%)

[bors]

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

[bors]

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

[Zoxc]

This no longer appears to be an improvement:

Benchmark	Before	After		Before	After		Before	After
	Time	Time	%	Physical Memory	Physical Memory	%	Committed Memory	Committed Memory	%
🟣 clap:check:unchanged	0.2469s	0.2466s	-0.11%	98.87 MiB	98.88 MiB	0.01%	163.95 MiB	164.07 MiB	0.07%
🟣 hyper:check:unchanged	0.1071s	0.1069s	-0.20%	62.81 MiB	62.75 MiB	-0.09%	120.05 MiB	120.06 MiB	0.02%
🟣 regex:check:unchanged	0.1864s	0.1878s	0.72%	80.26 MiB	80.52 MiB	0.33%	141.22 MiB	141.56 MiB	0.23%
🟣 syn:check:unchanged	0.3799s	0.3802s	0.07%	119.78 MiB	119.80 MiB	0.01%	184.96 MiB	185.03 MiB	0.03%
Total	0.9204s	0.9215s	0.12%	361.72 MiB	361.96 MiB	0.07%	610.19 MiB	610.71 MiB	0.09%
Summary	1.0000s	1.0012s	0.12%	1 byte	1.00 bytes	0.07%	1 byte	1.00 bytes	0.09%

Benchmark	Before	After		Before	After		Before	After
	Time	Time	%	Physical Memory	Physical Memory	%	Committed Memory	Committed Memory	%
🟠 clap:debug:unchanged	0.4958s	0.4973s	0.29%	134.96 MiB	134.72 MiB	-0.18%	204.18 MiB	203.97 MiB	-0.10%
🟠 hyper:debug:unchanged	0.1713s	0.1712s	-0.06%	70.53 MiB	70.56 MiB	0.03%	128.74 MiB	128.78 MiB	0.03%
🟠 regex:debug:unchanged	0.3633s	0.3645s	0.31%	100.68 MiB	100.75 MiB	0.07%	159.10 MiB	159.18 MiB	0.05%
🟠 syn:debug:unchanged	0.6150s	0.6144s	-0.10%	145.76 MiB	145.92 MiB	0.11%	209.50 MiB	209.71 MiB	0.10%
Total	1.6454s	1.6473s	0.11%	451.93 MiB	451.94 MiB	0.00%	701.52 MiB	701.64 MiB	0.02%
Summary	1.0000s	1.0011s	0.11%	1 byte	1.00 bytes	0.01%	1 byte	1.00 bytes	0.02%