Don't loop if there are no pending obligations

[compiler-errors]

Another microoptimization. Let's see.

r? lcnr

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[compiler-errors]

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit 3213399 with merge 3684df7…

To cancel the try build, run the command @bors try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3684df7 (3684df799b20a3621a59bcb7911f030364b4188f, parent: 430d6eddfc6a455ca4a0137c0822a982cccd3b2b)

[rust-timer]

Finished benchmarking commit (3684df7): comparison URL.

Overall result: ✅ improvements - no action needed

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.

@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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.3%	[-1.1%, -0.1%]	7
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.8%, secondary -1.5%)

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

	mean	range	count
Regressions ❌ (primary)	2.8%	[2.8%, 2.8%]	1
Regressions ❌ (secondary)	0.8%	[0.8%, 0.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.9%	[-3.9%, -3.9%]	1
All ❌✅ (primary)	2.8%	[2.8%, 2.8%]	1

Cycles

Results (primary 0.1%, secondary -3.0%)

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

	mean	range	count
Regressions ❌ (primary)	3.6%	[3.6%, 3.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.4%	[-3.4%, -3.4%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	0.1%	[-3.4%, 3.6%]	2

Binary size

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

Bootstrap: 468.925s -> 466.162s (-0.59%)
Artifact size: 374.68 MiB -> 374.67 MiB (-0.00%)

[lcnr]

The fact that this is a perf improvement is wild to me and seems to indicate a larger opportunity.

If we don't bail eagerly, we call drain_pending(|_| true) which is just mem::take(&mut self.pending) and then drops the Default ThinVec again.

How hot are the different parts of this function?

• entry
• initial loop
• encountering 1 or more goals (if so, how many)
• more than 1 loop

I remember that in the old solver, we do the stalled_on check and then the actual fulfillment happens in an #[inline(never)] function.

I can imagine doing the same here and outlining the stalled_on check. I would generally like to know whether fulfillment ends up being pretty much just as hot as in the old solver 🤔