perf: Do not reevaluate goals on the changes on the very opaques registered by them

[ShoyuVanilla]

Originally written by @cynecx in rust-lang/rust-analyzer#23217 (comment)

Currently we track StalledOnOpaques with the number of opaques when we started to evaluate the goal.
This is correct and safe, but it makes the goals normalizes opaques, either by their own or their nested goals, to be evaluated once again b/c the num_opaques_in_storage is changed by themselves.

I think tracking the num_opaques_in_storage from the point we finished to evaluate the goal make sense, because..

• The only places we directly register opaques is when we evaluate Projection goals for opaques, and they are surely unaffected by skipping reevaluation.
• For the goals who have the above goals as nested goals are also unaffected, as registering some opaques from some nested goals still makes the other goals to be reevaluated in the fixed-point iteration.

[ShoyuVanilla]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: b6ebf68 (b6ebf68a1faeb76a18761a2b1b04e6f5c915b129)
Base parent: edc52f8 (edc52f87c28f328c61685a02c47887a5cec7d767)

[rust-timer]

Finished benchmarking commit (b6ebf68): comparison URL.

Overall result: ✅ improvements - no action needed

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.

@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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.3%	[-8.1%, -0.6%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.1%, secondary 1.8%)

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

	mean	range	count
Regressions ❌ (primary)	1.1%	[0.9%, 1.4%]	4
Regressions ❌ (secondary)	1.8%	[0.7%, 3.3%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[0.9%, 1.4%]	4

Cycles

Results (primary -3.4%, secondary -3.8%)

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)	3.9%	[3.9%, 3.9%]	1
Improvements ✅ (primary)	-3.4%	[-3.4%, -3.4%]	1
Improvements ✅ (secondary)	-4.4%	[-7.1%, -2.0%]	13
All ❌✅ (primary)	-3.4%	[-3.4%, -3.4%]	1

Binary size

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

Bootstrap: 472.928s -> 474.036s (0.23%)
Artifact size: 401.53 MiB -> 400.59 MiB (-0.23%)

[ShoyuVanilla]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 4c748d4 (4c748d49e460d3fb6a13542b752f79ec75e03b4d)
Base parent: d8df826 (d8df82673d5911b6112a85bf91d9adefb2c66a1a)

[rust-timer]

Finished benchmarking commit (4c748d4): 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.3%	[0.2%, 0.4%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.3%	[-8.1%, -0.5%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 2.6%)

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)	7.6%	[7.6%, 7.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -5.9%)

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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.9%	[-7.1%, -3.8%]	5
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.1%]	15
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.1%]	15

Bootstrap: 477.112s -> 475.949s (-0.24%)
Artifact size: 401.86 MiB -> 401.00 MiB (-0.21%)

[amirHdev]

I'm still getting familiar with this part of the solver and I may be missing something here 🙂 but while following the shared InferCtxtLike changes I noticed that this adds num_opaques_in_storage as a required method while the rust-analyzer implementation doesn't seem to implement it yet

Since this originally came from the r-a slowdown would the corresponding r-a implementation helper need to be added here as well?

[ShoyuVanilla]

I'm still getting familiar with this part of the solver and I may be missing something here 🙂 but while following the shared InferCtxtLike changes I noticed that this adds num_opaques_in_storage as a required method while the rust-analyzer implementation doesn't seem to implement it yet

Since this originally came from the r-a slowdown would the corresponding r-a implementation helper need to be added here as well?

I think we have two almost identical functions here and there that returns the number of opaques, aren't we? Am I missing something? 🤔

BTW I didn't mean to be extra clear on this PR (yet) since this is just an experiment so far, but to elaborate a bit more, this used to be(you could check the previous revision before the force push) closer to the original rust-analyzer attempt, with one difference. The original one sets num_opaques to the caller's number in the fulfillment, while this PR did it in goal evaluation. So the rust-analyzer one does it only for the root goal evaluation for obligations, while this PR did it for every goal.

And it actually improved the perf in opaque-heavy benchmarks(the first perf run). I originally thought that the reason why is what I have written in this PR's description, but I was a bit confused and it wasn't really, because the affected code is not triggered unless the evaluation result is HasChanged::No. So my hypothesis that it helps perf because it prevents reevaluation of the ambiguous goal on the very opaque types added by its previous evaluations because when the goal returns opaque types, we have HasChanged::Yes.

So the force-pushed change was an attempt to make this to match with my original hypothesis, to mark goals returning opaques but nothing other than them as HasChanged::No. Howerver, the perf wasn't improved (it was still better than the baseline though) but regressed actually. Yeah, so my original hypothesis is wrong.

I looked into that more and the actual reason why this made it faster was a bit subtle. It accidentally sidesteps the existing mistakes or some slow paths. It made things faster not because of some design improvements. But I haven't made it clear to details enough yet and that's why this is still a draft with unchanged implementations/descriptions