W3: plan steps seen sooner, RequiredBy in parallel, pooled tick buffer

[donislawdev]

W3 of the performance series that followed the external report (S-6, S-5 and the narrow part of S-3).

Plan steps are seen sooner (S-6)

The pause between two looks at an entry now doubles from 10 ms up to the 250 ms cadence, instead of a flat 250 ms. The first look still goes straight after the request.

Measured on a throwaway Windows Server 2025 machine, elevated, 8 processors, five warm cycles:

operation	real time, ms	bws step before, ms	bws step after, ms
Spooler stop	1.4-4.1	4-5	4-5
Spooler start	42.9-67.5	284-289	47-68
W32Time stop	6.3-19.4	260-272	17-25
W32Time start	34.5-41.6	277-289	44-71

An entry's wait hint is rounded up to a whole cadence before it becomes a deadline. That is where the flat cadence left it in effect, so a service that promised 50 ms and arrived at 240 ms without raising its check point is still reported as done rather than as timed out. Looking sooner never turns into giving up sooner.

Visible in the JSON of a plan: the milliseconds of each step get smaller. The shape does not change.

Not done, with the reason: holding the manager handle in WindowsScmControl. One status reading costs 0.19-0.23 ms, measured unelevated, so the saving is below the sleep granularity of Windows.

RequiredBy asks several entries at once (S-5)

Parallel.For around the existing ReadDependents, each call with its own manager handle (a shared handle measured slower), order held by index. Over 797 entries on 16 processors, unelevated: 155-167 ms one at a time, 19-40 ms after, every answer identical to the sequential one. ConcurrencyGuards carries the file with its reason.

The status tick rents its buffer (S-3, narrow part)

The enumeration block comes from ArrayPool, cut to the size the manager asked for and cleared, and ManagerBlocks.ReadEnumerationBuffer takes a span, so the reader sees the same length and the same zeros as with a new array. Over 1500 ticks: 347 KB allocated per tick became 217 KB, full collections went from 34 to 1, tick time unchanged. The rest of the report's S-3 proposal (a kept buffer with one call, a status walker without display names, a delta) is not done, for reasons in the analysis.

Guards

• PlanRunCadenceTests: arrival noticed soon (six arrival times), short promises get the patience they always had, a long wait asks the manager about every 250 ms.
• PlanRunnerTests: the three waiting tests assert ranges instead of multiples of 250 ms.
• RequiredByPassParallelTests: 400 entries keep their own answers in order against a single-threaded run, and the first two questions really go out together.
• Mutation entries: 8 new, 3 re-anchored or moved, 11 of 11 caught.
• Narrow runs: core classes touched 94/94 and 22/22, integration runs=anywhere 24/24, window ColumnFamilyGuards 2/2, architecture 182/182. No full suite.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Repository UI (base), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 6642b577-6239-4025-b163-5f0aff8fb26a

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}