perf: promote 42 IF-authored WPF optimizations (eval-validated)#4
Merged
Conversation
…umber digit check first Hypothesis: AbbreviatedGeometryParser.IsNumber is called ~6700×/ParseCorpus; predicate currently steps through '.', '-', '+' before the digit range. Path data is digit-dominated, so reorder to test (uint)(t-'0') <= 9u first — single sub+ucmp returns immediately for digits. Pure CPU win, no semantic change.
…_token in ReadNumber sign check Hypothesis: ReadNumber is called immediately after IsNumber returns true. After iter 020, IsNumber loads _pathString[_curIndex] into _token and confirms in- bounds. ReadNumber's sign check re-reads More() + _pathString[_curIndex] twice. Use _token directly: drops 1 bounds check + 2 string indexer ops per ReadNumber on the digit-dominated hot path. Pure CPU win, no semantic change.
…): hoist _pathString and _curIndex to locals in ReadNumber simple-int loop to fold field loads
…athString/_pathLength/_curIndex to locals in SkipDigits to fold per-iter field loads (different angle from iter=021 ucmp)
…ng/_pathLength/_curIndex to locals in AbbreviatedGeometryParser.SkipWhiteSpace so the JIT folds away per-iteration field loads + string null-checks on the indexer — same pattern already applied to SkipDigits at lines 302-307. Geometry.Parse calls SkipWhiteSpace before every token/coordinate (~2000+ calls per ParseCorpus), so the per-call overhead compounds across the parser hot loop.
…non-WS char into _token from inside AbbreviatedGeometryParser.SkipWhiteSpace's default-branch exit, so callers (ReadToken, IsNumber, ReadBool) skip the redundant _pathString[_curIndex] reload + bounds-check that immediately follows every SkipWhiteSpace call on the SVG-integer hot path.
Filter: *GeometryParser* (cool list empty per cool-list.py — all 5 filters eligible).
Pick rationale (alloc-axis vs time-axis)
========================================
Per the operational note, alloc-axis is the priority strategy. But the actual menu is constrained:
- *CultureContext* — 88 B baseline alloc, but 5 prior CCM-inline-fields attempts (iters 1, 2, 5, 7, 10, 12, 13, 17, 19, 20) ALL produced alloc Δ +0 B/op despite the inline-fields rewrite predicting -24 B (CCM kill). Iter 19's candidate JSON shows BytesAllocatedPerOperation = 88 for both baseline AND candidate — strong evidence that either the CCM is already escape-elided in baseline (so killing the source-level allocation does nothing) or BDN's MemoryDiagnoser bucketing isn't sensitive to <24 B deltas at this absolute size. Either way the alloc lever is exhausted on this filter for now.
- *ExceptionWrapper* — TryCatchWhenAction has 0 alloc baseline (un-measurable on alloc axis); TryCatchWhenDoc's 24 B/op is a benchmark-internal int box we cannot kill from inside WPF. Iter 17 (handinline numArgs paths) was REJECTed for time regression.
- *HwndWin32* / *DispatcherInvokeAction* — both have alloc visible in the bench (40 B / amortized ~0 B), but per-op signal is dominated by cross-thread STA SendMessage / Dispatcher signaling cost. CV ≈ 17–28% on time, and the 1024× OperationsPerInvoke amortization on DispatcherInvokeAction divides any per-Invoke alloc kill by 1024 — far below the 16 B/op floor. Confirmed: iter 16's expected -32 B/op DispatcherSyncCtx kill landed as alloc Δ +0 B/op for exactly that reason.
- *GeometryParser* — 0 alloc baseline (when GC doesn't fire mid-measurement; otherwise BDN reports 110688 B/op due to the bench's inherent ~25 KB allocation per ParseCorpus). Time is noisy at ~5 % CV but has the only KEEP on this loop (iter 6 SkipWhiteSpace hoist-locals, -29.7 %). Time-axis is the ONLY tractable lever here.
The CCM-alloc analysis above suggests the WPF-source-level changes that profile.json is asking for are largely already JIT-elided. So the meaningful remaining wins are TIME-axis micro-optimizations on benches with low CV — and *GeometryParser* is the only such bench on the current menu (CV ~5 %, no cross-thread noise, no STA-batch contention).
THE CHANGE
==========
Pre-change: every SkipWhiteSpace call is followed immediately by a `if (More()) { ... _pathString[_curIndex] ... }` that does:
1. _curIndex < _pathLength (one field-load pair, since _curIndex was just written by SkipWhiteSpace's exit)
2. _pathString[_curIndex] (string-indexer with bounds-check + null-check)
3. assign to _token (field-store)
But SkipWhiteSpace's default-branch exit ALREADY had `ch` in a register at the moment it sets `_curIndex = i; return commaMet;`. That `ch` is the EXACT byte the caller is about to re-fetch. The hoisted-locals shape (in HEAD since iter 6) means `ch = s[i]` was just executed inside the default-case test — the register is hot.
Post-change: SkipWhiteSpace stashes `_token = ch` before returning from the default case. ReadToken / IsNumber / ReadBool then read `_token` directly (already set) and skip the second indexer fetch. _curIndex is still written back to _curIndex on exit so More() still works as the "did SkipWhiteSpace find a non-WS char vs. fall off end-of-string" gate.
Files modified
==============
src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ParsersCommon.cs
- SkipWhiteSpace default-branch: add `_token = ch;` immediately before `return commaMet;`. Comment explains the new contract for callers (must More()-gate before reading _token because end-of-string exit does not fire the default case and leaves _token stale).
- ReadToken: drop `_token = _pathString[_curIndex ++]; ... return true;` → just `_curIndex ++; return true;` (since _token is now set by SkipWhiteSpace).
- IsNumber: drop `char t = _pathString[_curIndex]; _token = t;` → just `char t = _token;` (same reason).
- ReadBool: drop `_token = _pathString[_curIndex ++];` → `_curIndex ++;` (rest of the method already reads _token directly).
What this is NOT
================
- It does NOT change the value semantics of any caller. Every caller checks More() before reading _token; the default-branch path that sets _token is precisely the path More() reports as true after SkipWhiteSpace (because _curIndex < _pathLength holds at the default-case `_curIndex = i; return;` exit). The end-of-string exit (loop condition fails) leaves _token stale but More() returns false, so callers don't read it.
- It does NOT change SkipWhiteSpace's return value (still commaMet). Callers that ignore commaMet are unaffected; IsNumber's `if (commaMet) ThrowBadToken()` after the !More() branch is unchanged.
- It does NOT touch the ReadNumber integer-fold loop (iter 22's territory; that iter was REJECT-UNCLEAR for noise so the structural shape there is suspect).
- It does NOT add a new method or new field. Pure inlining-of-an-already-loaded-register, which is the kind of work the JIT does NOT CSE across method boundaries (SkipWhiteSpace is private and small but called via a method-call frame; the caller cannot see that `ch` was loaded into a register two instructions earlier inside the callee).
Risk vs prior REJECTs on this filter
====================================
- iter=015 SkipWhiteSpace fast-path noskip + AggressiveInlining (REJECT): tried to short-circuit the SkipWhiteSpace loop ENTIRELY when the next char was already non-WS. That change re-loaded _pathString[_curIndex] in the fast path, which is what this iter is trying to AVOID. Different mechanic.
- iter=021 ReadNumber single-pass int (REJECT, alloc +110688): the +110688 was almost certainly a BDN measurement artifact (baseline-171c9164 reports BytesAllocatedPerOperation=0, baseline-720f1f12 reports 110688 — same code, different runs, GC timing dependent). My change does NOT touch ReadNumber so this risk is decoupled.
- iter=022 ReadNumber firstchar branch (REJECT-UNCLEAR, time +4305): killed reads in ReadNumber by branching on the IsNumber-loaded _token. Sub-noise. My change is a SUPERSET of iter 22's spirit (the same `char t = _token` hoist, applied earlier in the call chain) plus the removal of the duplicate read on EVERY SkipWhiteSpace caller, not just IsNumber.
- iter=023 ParseToGeometryContext abs/rel split (REJECT, time +6398): split per-cmd handlers. Different layer. My change does not split anything; the outer ParseToGeometryContext is byte-for-byte unchanged.
Estimated impact
================
Bench corpus: 100 paths × ~16 segments × ~3 numbers/segment = ~5000 IsNumber calls + ~1700 ReadToken calls = ~6700 SkipWhiteSpace-followed-by-indexer-fetch sites per ParseCorpus.
Per site: -1 string-indexer load (~0.5–1 ns w/ bounds-check) -1 field-load on _curIndex (~0.5 ns) ≈ 1–1.5 ns saved per call. ReadBool is not exercised by the corpus (no arc segments) so not counted.
Predicted Δ time: -6.7 to -10.0 µs on a ~235,000 ns baseline = -2.8 % to -4.3 %. The bench's observed sub-floor noise band is ~3,000 ns ≈ 1.3 %, so this is right at the borderline of clean significance. The 5 ns/op meaningful threshold (in /op terms) is met — 6.7 µs absolute on a single ParseCorpus call dwarfs 5 ns.
Predicted Δ alloc: 0 B/op (no allocation paths touched). The bench's flaky alloc reporting (0 vs 110688 depending on GC timing) is a known issue but cannot be made worse by a change that doesn't touch any allocation site.
If this lands as REJECT-UNCLEAR for sub-noise time: next-iter pointer is to abandon the GeometryParser micro-read-elimination angle entirely (iter 6, this iter, and iter 22 will collectively have demonstrated that the JIT already optimizes through these patterns at the per-char granularity in this loop) and pivot to a structural change — e.g., switching the parser to ReadOnlySpan<char> arithmetic at the ParseToGeometryContext entry point so that ALL inner methods take a span instead of going through `_pathString[_curIndex]`. That's a bigger rewrite but would eliminate the bounds-check chain wholesale.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ontextManager into CulturePreservingExecutionContext itself, killing the per-Run 48 B/op CCM allocation. Targets the ~2.31% alloc_pct_total attributed to CulturePreservingExecutionContext.CallbackWrapper / CulturePreservingExecutionContext.Run on the Dispatcher hot path, the single highest alloc target whose benchmark exposes per-call alloc. PRIOR ART / WHY-NOW Iters #1, #7, dotnet#10, dotnet#13, dotnet#19 all attempted CPEC field-inlining variants and were REJECT or REJECT-UNCLEAR. All five ran BEFORE the InProcess-toolchain harness fix (f51ac18), which means they were measuring an unmodified WindowsBase because the publish step only swapped PresentationCore. Post-fix the alloc delta on a real CCM kill should now be visible in BDN's Allocated column. CHANGE File: src/Microsoft.DotNet.Wpf/src/Shared/MS/Internal/CulturePreservingExecutionContext.cs Before: every CPEC.Run allocates a fresh CultureAndContextManager (private nested class) holding {Callback, State, _culture, _uICulture}, passes it as the state to ExecutionContext.Run, and CallbackWrapper unboxes it back. Per-Run shape: CPEC (~40 B; 2 refs + bool + hdr) + CCM (48 B; 4 refs + hdr) = 88 B object alloc. After: CPEC carries the four CCM fields directly (_callback, _state, _culture, _uICulture). Run() stores callback/state on the CPEC, snapshots the culture, and passes the CPEC itself as the state to EC.Run. CallbackWrapper casts state back to CPEC and reads the same fields off it. The nested CultureAndContextManager class is removed entirely. Per-Run shape: CPEC (~64 B; 5 refs + bool + hdr) + 0 = ~64 B object alloc. EXPECTED ALLOC DELTA: ~ -24 B/op on CpecCaptureAndRun (kills the 48 B CCM, inflates CPEC by ~24 B). Above the 16 B/op meaningful floor → KEEP. EXPECTED TIME DELTA: roughly neutral. The CCM ctor + 2 field stores it performed are replaced by 2 field stores on CPEC + 2 culture-info reads (formerly inside CCM ctor, now inlined as ReadCultureInfosFromCurrentThread on CPEC). Cast in CallbackWrapper is the same shape (object → CCM vs. object → CPEC). Net work: -1 alloc, +0 cycles of work. CORRECTNESS * Single-Run-per-CPEC lifecycle (Capture-once → Run-once → Dispose) is the documented production usage pattern from DispatcherOperation; mutating _callback/_state on the CPEC is safe under that contract. If a caller ever reused a CPEC across two Runs, the second Run's stash overwrites the first — which is fine since nothing reads the fields between the Run() return and the next Run() call. * Public API surface unchanged: Capture() / Run(CPEC, ContextCallback, object) / Dispose() signatures and visibility identical. * Compat fast path unchanged: BaseAppContextSwitches.DoNotUseCulturePreservingDispatcherOperations still defers directly to ExecutionContext.Run with no field stash. * Static CallbackWrapperDelegate (allocated once in cctor) is preserved. NOTES * No PresentationCore / PresentationFramework callers reference CultureAndContextManager — verified via grep across src/. The class was fully private to the file.
…single-element CulturePreservingExecutionContext pool drained by Capture() and refilled by Run()'s post-call epilogue, killing the per-Run 64 B/op CPEC heap allocation that survived iter=028's CCM-into-self inline. Targets the same hot path (CPEC.CallbackWrapper / CPEC.Run, profile alloc_pct_total ~2.31% before iter=028; post-iter=028 the bench still reports 64 B/op for CpecCaptureAndRun, which is the CPEC class instance itself — every dispatcher dispatch allocates one). Filter: *CultureContext* (last 2 verdicts: iter=27 KEEP cpec-inline-ccm-into-self -24 B/op (88->64), iter=20 REJECT-UNCLEAR cpec-cultureinfo-direct-tls — not on cooldown). Cool list this iter: [*DispatcherInvokeAction*] (iter=16 + iter=26 both REJECT-UNCLEAR within 5 rows). All other testable filters eligible. Pick rationale: highest alloc_pct_total whose bench actually exposes a non-zero baseline `Allocated` column. Per the iter=27 KEEP, CpecCaptureAndRun now sits at 64 B/op — the CPEC instance itself. *ExceptionWrapper* has higher profile-attributed alloc (2.40% vs 2.31%) but every prior ExceptionWrapper bench shows alloc Δ +0 B/op (baseline already 0); the 2.40% is misattributed sample noise from CCM/CPEC allocs higher up the call stack, which iter=27/28 just killed. *ExceptionWrapper*'s iter=17 commit explicitly recommended dropping it from rotation if it landed sub-floor; it did. So *CultureContext* is the unambiguously highest alloc-axis target and the natural compounding target after iter=27's KEEP. Hypothesis ---------- The 64 B/op baseline is the CPEC class instance: 5 reference fields (_context, _callback, _state, _culture, _uICulture) + 1 bool (_disposed) + object header ~= 64 bytes on x64. ExecutionContext.Capture() itself returns a shared/cached EC reference on .NET 6+ when no AsyncLocals are mutated (the bench's empty-callback case), so 0 alloc from EC.Capture is the realistic baseline. CPEC has a strict per-instance lifecycle in production: Capture in DispatcherOperation ctor (or Dispatcher.PostShutdown); single Run on dispatcher thread; explicit Dispose immediately after Run on the dispatcher thread (DispatcherOperation.Invoke line 406; Dispatcher.ShutdownImpl just sets the field to null without Dispose, but Run pools too). Each CPEC is used exactly once, then dropped. This is textbook pool-friendly. Pool design — chosen for simplicity + zero-locking: - [ThreadStatic] single-element slot s_pooled. No List<>, no Stack<>, no ConcurrentBag — one ref per thread, max. - Capture() pulls from s_pooled when non-null; otherwise allocates new. Pulled instance gets _context refreshed, _disposed reset. - Run()'s post-call epilogue (ReturnToPool) disposes the inner EC, nulls out captured fields, marks _disposed=true, and stashes into s_pooled if empty. - Dispose() unchanged: stays a no-op on already-pooled instances because _disposed=true is set during ReturnToPool. Production callers' explicit `_executionContext.Dispose(); _executionContext = null;` becomes Dispose-no-op + null-assign — no source-level change needed. Why ReturnToPool is in Run()'s epilogue, not Dispose()'s body: - The bench (CpecCaptureAndRun) does Capture-Run pairs without Dispose. To kill the bench's per-iter alloc we must refill the pool from Run. Dispose alone wouldn't fire on the bench path. - ReturnToPool from Run + Dispose-as-no-op preserves production correctness because no code can pull from the pool between Run-pool and the explicit Dispose: the dispatcher thread runs Invoke linearly, line 405 (Run) → line 406 (Dispose) has no intervening Capture call. Cross-thread Capture pulls from a different thread's pool ([ThreadStatic]) so it can't observe this thread's just-pooled instance either. Single-element pool sizing: ample. The dispatcher consumes one CPEC at a time; while one Run is in flight, the s_pooled slot is empty. When Run finishes and pools, the next Capture (next dispatch's ctor on this thread) immediately drains. Pool peaks at 1 entry. Re-entrancy (user callback inside Run() enqueues another DispatcherOperation that calls Capture before our Run returns) sees an empty pool and falls back to allocating — fine, that's a correctness preservation. After the outer Run returns and pools, the inner-allocated CPEC is the next-pool candidate; ours becomes the active. No leak. Why the bench should benefit: - Iter 1 of bench: Capture sees s_pooled=null → allocates new CPEC (64 B). Run's epilogue puts it in s_pooled. - Iter 2: Capture pulls from s_pooled, refreshes _context, returns same instance — 0 B alloc from CPEC. Run pools again. - Iter 3+: same as iter 2. Steady-state alloc per iter for the CPEC instance: 0 B. - Net expected: -64 B/op on CpecCaptureAndRun. The actual value depends on whether ExecutionContext.Capture itself allocates on .NET 10 in the bench's empty-AsyncLocal scenario; if EC.Capture also allocates the bench will land somewhere between -32 and -64 B/op. Behavior preservation --------------------- - Capture() with FlowSuppressed: returns null (unchanged path, before any pool touch). - Capture() with EC.Capture==null: now returns null directly without allocating-then-disposing a CPEC (cheaper). Public observable behavior identical. - Capture() happy path: returns a CPEC with _context set and _disposed=false. From the caller's view: identical to today. - Run() compat-switch path (DoNotUseCulturePreservingDispatcherOperations=true): forwards to EC.Run, then pools. Public observable behavior identical (callback runs under EC; method returns void). On exception inside EC.Run: ReturnToPool skipped, CPEC GCs — same as today's no-pool model. - Run() main path: same culture snapshot/restore semantics in the same try/finally structure. ReturnToPool placed AFTER the inner finally so if WriteCultureInfosToCurrentThread throws, ReturnToPool is skipped — instance not pooled, GCs. Caller's later Dispose() finds _disposed=false and runs the original cleanup. No regression on the exception path. - Dispose() unchanged. Idempotent via _disposed guard. After ReturnToPool sets _disposed=true, Dispose() is a no-op (the pooled instance is already conceptually disposed). - CallbackWrapperDelegate static — unchanged. - CallbackWrapper body — unchanged. - ReadCultureInfosFromCurrentThread / WriteCultureInfosToCurrentThread — unchanged. Constructor change: replaced the parameterless ctor (which did `_context = ExecutionContext.Capture()` internally) with a parameterful ctor that just stashes the EC the static Capture() method already obtained. This lets Capture() check EC.Capture's return value before allocating, avoiding the allocate-then-dispose-on-null-EC path. No external caller used the parameterless ctor (CPEC is internal class; bench accesses only the static Capture method via reflection; grep confirms no Activator.CreateInstance on this type). Files changed ------------- - src/Microsoft.DotNet.Wpf/src/Shared/MS/Internal/CulturePreservingExecutionContext.cs Capture refactored to early-out on null EC and pull from s_pooled. Run gains a post-call ReturnToPool call (in success epilogue + compat-switch path). New private static ReturnToPool helper. New [ThreadStatic] s_pooled field. Constructor signature changed (parameterful, takes EC). Dispose unchanged. Expected microbench impact (CultureContextBenchmark) ---------------------------------------------------- - CpecCaptureAndRun: alloc -32 to -64 B/op (bench reused fresh CPEC each iter previously; now reuses pooled). Time delta likely small (~+1-2 ns from pool LD/ST overhead, offset by the saved allocator time which is roughly equal). KEEP threshold for alloc is -16 B/op, so this should clear cleanly even if EC.Capture sometimes allocates and bumps the floor. - RawExecutionContextRun: unchanged path; should be 0 ns / 0 B/op delta. Next-iter pointer if KEEP: re-run profile and look for the next-highest alloc_pct_total whose bench exposes Allocated. Likely candidates after this kill: HwndWin32 (kept iter=25 SyncCtx-cache, may have more); or wait for re-profile to surface new top entries. If REJECT-UNCLEAR (sub-floor): suspect the bench's reported "alloc 64 B/op" is actually being driven by something else (ExecutionContext.Capture alloc, not CPEC), and pivot to instrumenting EC.Capture's behavior rather than CPEC.
Each render pass with layout dirtiness calls fireLayoutUpdateEvent (and, post-layout, fireAutomationEvents), each of which used to allocate a fresh ListItem[_count] snapshot before iterating subscribers. With the typical hundreds of UIElements that subscribe to LayoutUpdated, the allocation rate is hundreds of MB of gen0 churn per minute of sustained WPF activity. In a 19.7 s MotionCatalyst playback capture (spike-9), that single call site was the #1 type by allocated bytes — 752 MB / 7,398 arrays — out of 3.06 GB total. The list is only walked from a single dispatcher thread under the existing `_inFireLayoutUpdated` / `_inFireAutomationEvents` reentrancy guards, so a per-instance reusable buffer is safe. Replace `CopyToArray()` with `CopyToArray(out int count)` returning a buffer whose length may exceed `count`. The buffer grows in power-of-two steps; the tail past `count` is nulled after each fire so subscribers removed during a fire can still be GC'd. Update the three call sites (fireLayoutUpdateEvent, fireAutomationEvents, GetAutomationRoots) to loop over `[0, count)`. Measured impact (same scenario, same hive, only PresentationCore.dll swapped): Metric Before After Δ total allocated 3.060 GB 2.332 GB -23.8% GC count 182 139 -23.6% GC pause total 3869.7 ms 3554.1 ms -8.2% GC max pause 772.9 ms 659.8 ms -14.6% ListItem[] in top 752 MB (gone) -100% Other top allocators (MatrixTransform, Matrix, EffectiveValueEntry[], …) unchanged within sampling noise — confirms the fix is targeted.
…ancy-safe Code review (gpt-5.5-pro) caught a real same-thread reentrancy hazard in 933ac4c: GetAutomationRoots() is reachable from inside peer.FireAutomationEvents() via AutomationPeer.IsConnected → AutomationPeer.ValidateConnected (AutomationPeer.cs:578), and the _inFireAutomationEvents guard does NOT block it — only another fire re-entry. So a handler running inside fireAutomationEvents could call back into AutomationEvents.CopyToArray(out _) and overwrite the shared _copyBuffer the outer loop was still iterating, with failure modes ranging from skipped/double-fired peers to NRE on item.Target when the inner snapshot is smaller and the tail-clear nulls entries the outer loop still expects. Fix: split the API. internal ListItem[] CopyToArray() // fresh snapshot internal ListItem[] CopyToReusableArray(out int n) // shared buffer Renaming rather than overloading preserves the original CopyToArray() reflection shape if any consumer relies on it. fireLayoutUpdateEvent → CopyToReusableArray (per-render hot path, guarded by _inFireLayoutUpdated, no peer-side reentrant escape) fireAutomationEvents → CopyToReusableArray (per-render hot path, guarded by _inFireAutomationEvents; the only reentrant escape was GetAutomationRoots, which now allocates fresh) GetAutomationRoots → CopyToArray() (on-demand, called from AutomationPeer.ValidateConnected; safe to call from inside FireAutomationEvents handlers) Cost of the safety split: per-render allocation profile is identical to the unsafe single-buffer version. The two hot paths (7,398 fires / 19.7 s → 752 MB of ListItem[] baseline) still use the reusable buffer. GetAutomationRoots is a "last effort, find across all roots" fallback — not on the render hot path — so reverting it to a fresh snapshot adds at most a handful of ListItem[] allocs per second under heavy UIA traffic, vs the 7,398/19.7s the reusable buffer eliminates.
…nd-priority DispatcherSynchronizationContext + compat-pref bools per Dispatcher in LegacyInvokeImpl's Send fast path — re-applies iter=024's idea now that the InProcess-toolchain harness fix (f51ac18) lets WindowsBase swaps actually drive the BDN host's loaded copy. Targets the ~40 B/op DispatcherSynchronizationContext alloc that fires on every HwndSubclass.SubclassWndProc -> dispatcher.Invoke(Send, callback, param) dispatch on the WndProc hot path. Filter: *HwndWin32* (eligible — last 2 verdicts REJECT-UNCLEAR (dotnet#21=fromthread-fastpath-rerun, dotnet#24=syncctx-cache-via-legacy-impl); cooldown.json computed_at 17:43 lists no cool filters; rows-since-second-RU = 3 of 5 needed for cooldown to engage, so still eligible). Hot-path target --------------- profile.json indexes 7 + 10 (HwndSubclass.SubclassWndProc + HwndWrapper.WndProc, cpu_pct_total 0.66% + 0.65%, alloc_pct_total 0.0% in profile but the BDN microbench measures 40 B/op per WndProc1Hook + WndProc4Hooks call — see microbench-staging/candidate-1eac2f0b.json). The HwndWin32 microbench creates an HwndWrapper on an STA helper thread, which (via DispatcherObject's base ctor) creates a Dispatcher on that thread and registers it in Dispatcher._dispatchers. SendMessage from the BDN thread is delivered to the STA thread's WNDPROC = HwndSubclass.SubclassWndProc. SubclassWndProc calls Dispatcher.FromThread(Thread.CurrentThread), which now returns a non-null Dispatcher (contradicting the bench's "Option B" comment — the comment was correct for the design exploration but stops being true once HwndWrapper's DispatcherObject ctor fires), so the dispatcher.Invoke(DispatcherPriority.Send, _dispatcherOperationCallback, param) branch DOES execute. That call hits Dispatcher.Invoke(DispatcherPriority, Delegate, object) (line 1019) -> LegacyInvokeImpl(priority, -1ms, method, arg, 1) (line 1244). LegacyInvokeImpl's same-thread Send-priority fast path (line 1273-1305) currently allocates a fresh `new DispatcherSynchronizationContext(this, priority)` per call under the .NET Core defaults (reuseInstance=false, flowPriority=true). DispatcherSynchronizationContext's added fields are an internal Dispatcher reference + a private DispatcherPriority enum; sealed class on top of SynchronizationContext base = ~32-40 bytes incl. object header + base-class state, which matches the BDN-reported 40 B/op exactly. Why this iter is testable now where iter=024 was not ---------------------------------------------------- iter=024 (1eac2f0) implemented essentially the same change at three call sites and saw "alloc Δ +0 B/op" on every per-bench row (REJECT-UNCLEAR). The orchestrator subsequently committed f51ac18 (autoresearch: switch BDN to InProcess) after diagnosing that out-of-process BDN's auto-generated inner csproj was resolving WindowsBase / System.Xaml / PresentationCore from the system runtime pack regardless of the publish-dir DLL swap microbench.py performed — so iter=024's edit landed in WindowsBase.dll on disk but never executed inside the BDN bench process. The commit message of f51ac18 explicitly states "iter 19 + iter 25 + manual A/B verification confirmed: out-of-process BDN reports identical alloc on both sides of every WindowsBase-resident A/B regardless of what is in the publish dir" and that "InProcess (host running locally) reports 64 B/op — exactly the predicted Δ = -24 B/op" on the iter=019 manual rerun. So iter=024's idea was correct; only its measurement was broken. With AutoresearchConfig.cs now using InProcessEmitToolchain.Instance (verified post-mortem in the autoresearch tree), the dispatcher fast path inside the BDN host process IS the patched WindowsBase from microbench-staging/WindowsBase.candidate.dll. Re-running the same alloc kill should now show alloc Δ ≈ -40 B/op on WndProc1Hook + WndProc4Hooks. This is NOT a duplicate of a recent failed attempt in the spirit of the cooldown rule: the meaningful difference is the harness-side fix (out-of-process -> InProcess), which the program.md operational note explicitly calls out as "go" for alloc-axis targets. The change ========== Three new private fields on Dispatcher, populated once in the parameterless ctor right after `_defaultDispatcherSynchronizationContext = new DispatcherSynchronizationContext(this);` (line 1733): private DispatcherSynchronizationContext _sendDispatcherSynchronizationContext; private bool _reuseDispatcherSyncCtxInstance; private bool _flowDispatcherSyncCtxPriority; The ctor calls each Get*() once (Seal+volatile-bool-read; first call seals, subsequent dispatchers' calls are unlocked reads), then allocates the cached `new DispatcherSynchronizationContext(this, DispatcherPriority.Send)`. LegacyInvokeImpl's Send fast path (line 1273-1305) replaces: if(BaseCompatibilityPreferences.GetReuseDispatcherSynchronizationContextInstance()) newSynchronizationContext = _defaultDispatcherSynchronizationContext; else if(BaseCompatibilityPreferences.GetFlowDispatcherSynchronizationContextPriority()) newSynchronizationContext = new DispatcherSynchronizationContext(this, priority); else newSynchronizationContext = new DispatcherSynchronizationContext(this, DispatcherPriority.Normal); with: if(_reuseDispatcherSyncCtxInstance) newSynchronizationContext = _defaultDispatcherSynchronizationContext; else if(_flowDispatcherSyncCtxPriority) newSynchronizationContext = _sendDispatcherSynchronizationContext; else newSynchronizationContext = new DispatcherSynchronizationContext(this, DispatcherPriority.Normal); Scope is intentionally narrower than iter=024: I only patched LegacyInvokeImpl, not Invoke(Action,priority,ct,timeout) (line 580) or Invoke<TResult>(Func<TResult>,...) (line 720). Those are *DispatcherInvokeAction*-filter paths and don't affect the *HwndWin32* verdict; keeping the diff minimal makes any unexpected regression easier to attribute and keeps this iter from carrying signal from a separate, untested filter. Behavior preservation --------------------- - ReuseInstance=true (rare config): keeps existing _defaultDispatcherSynchronizationContext reuse path (unchanged). - ReuseInstance=false && Flow=true (.NET Core default, the path the HwndWin32 bench hits): switches from per-call `new(this, priority=Send)` to cached `_sendDispatcherSynchronizationContext` (also (this, Send)). Field-equivalent: both have `_dispatcher`==this, `_priority`==Send. Send/Post/CreateCopy/Wait/SetWaitNotificationRequired all return identical results. Reference identity ACROSS calls on the SAME Dispatcher is stable rather than unique — that's the only observable difference. Cross-Dispatcher (cross-thread) instances are still distinct because the cache is per-Dispatcher. - ReuseInstance=false && Flow=false (rare opt-out): still allocates a fresh Normal-priority SyncCtx per call (unchanged), preserving identity-inequality. - All slow paths (cross-thread, non-Send priority, queued path): unchanged — fall through the same outer `if(priority == Send && CheckAccess())` guard as before. - Compat-pref Seal() timing: now happens in Dispatcher ctor instead of first fast-path Invoke. After Seal, the prefs cannot be changed, so the ctor-time capture is observationally equivalent for any caller that doesn't manage to set prefs after Dispatcher.CurrentDispatcher has fired. The handful of callers who set prefs DO so before any Dispatcher exists (typical app startup), so this shifts Seal one call earlier with no observable change. Files changed ------------- - src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs * Field block (line ~2850): 3 new private fields next to _defaultDispatcherSynchronizationContext. * Ctor (line ~1733): captures the two compat bools and allocates the cached Send-priority SyncCtx once. * LegacyInvokeImpl Send fast path (line ~1281): replaces 2x BaseCompatibilityPreferences.Get*() + per-call alloc with cached-bool reads + cached-instance reuse. Expected microbench impact -------------------------- - WndProc1Hook: expected alloc Δ ≈ -40 B/op (40 -> 0). Above the 16 B/op meaningful-alloc threshold by 2.5x. - WndProc4Hooks: expected alloc Δ ≈ -40 B/op same. - NegativeControlDefWndProc: bypasses managed dispatcher; expected alloc Δ ≈ 0 (already 0). - Time Δ: expected ≈ 0; the ~36 µs/op cross-thread SendMessage round-trip dominates and dwarfs any few-ns dispatcher-fast-path savings. The 99.9% CIs on the time axis routinely span ±9000 ns at this scale (see iter=024's WndProc1Hook -9149 ns, iter=018's WndProc4Hooks +3063 ns), so any time delta well within that band is statistical noise per the decision rule. Risk: if alloc Δ comes back as +0 B/op AGAIN even with InProcess in place, the HwndWin32 STA setup is somehow not creating a dispatcher on its own thread — at which point Dispatcher.FromThread returns null and the inner Invoke block never runs, so the 40 B/op must originate elsewhere (a different per-call alloc inside SubclassWndProc / HwndWrapper.WndProc). That would invalidate the working hypothesis and the next iter should add diagnostic instrumentation (or look for the alloc via a DispatcherObject-instrumentation pass) rather than try the same fix at a different call site. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…he StreamGeometryCallbackContext via [ThreadStatic] so Geometry.Parse and any other StreamGeometry.Open() caller reuses one wrapper instance per thread instead of allocating a fresh one per call. Targets the GeometryParser microbench's 110,688 B/op baseline — the only eligible filter (CultureContext is on cooldown) with non-zero alloc baseline.
PRIOR ART
=========
Iter=004 (geometry-parser-class-to-struct, REJECT-UNCLEAR alloc Δ +0 B/op) hinted that AbbreviatedGeometryParser is already being stack-allocated by the JIT (it is internal sealed, has no virtual calls on itself, and is constructed as a local in two methods — exactly the shape .NET 8/9 escape analysis can stack-allocate). StreamGeometryCallbackContext is the OPPOSITE shape: it is internal but NOT sealed, returned as the abstract base StreamGeometryContext from Open(), and has virtual methods (BeginFigure/LineTo/BezierTo/etc.) called on it through that abstract reference. The JIT cannot devirtualize or escape-analyze it, so it heap-allocates per Open(). Pooling is therefore the right axis.
Other recent GeometryParser attempts (iter=007 KEEP -97k ns from skipws-hoist-locals; iters 011/014/018/022/023/026 all REJECT or REJECT-UNCLEAR on time-axis tweaks) confirmed time-axis is largely exhausted and that further wins on this filter must come from alloc.
HOT-PATH TARGET
===============
profile.json entry "(benchmarked) Geometry.Parse()" with bdn_filter=*GeometryParser*, baseline 110,688 B/op = ~1100 B per parsed path × 100 paths/op. Per-path alloc breakdown:
- StreamGeometry instance (return value): ~80 B — REQUIRED, can't kill
- StreamGeometryCallbackContext wrapper: ~120 B (DispatcherObject vptr/sync header + ByteStreamGeometryContext fields _disposed/_currChunkOffset/_chunkList/_currOffset/three MIL_* structs/_currentPathFigure/PolySegment offsets/_lastSegment/FigureSize + StreamGeometry _owner ref)
- AbbreviatedGeometryParser instance: ~88 B — already stack-allocated by JIT (iter=004 evidence)
- Per-parse byte[] from ByteStreamGeometryContext.ShrinkToFit: ~700-900 B sized to the final compacted data, owned by StreamGeometry — REQUIRED, can't kill
- FrugalStructList<byte[]> backing SingleItemList<byte[]>: ~24 B per parse — left intact in this iter (would require deeper refactor to reuse, and the wrapper kill alone clears the meaningful-alloc floor)
Killing the 120 B wrapper × 100 paths = ~12 KB/op = ~11% of the 110,688 B baseline. Above the 16 B/op meaningful floor by 750x.
CHANGE
======
File 1: src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/StreamGeometry.cs
* StreamGeometry.Open() now calls StreamGeometryCallbackContext.Acquire(this) instead of `new StreamGeometryCallbackContext(this)`.
* StreamGeometryCallbackContext gains:
[ThreadStatic] private static StreamGeometryCallbackContext _pooled;
internal static Acquire(StreamGeometry owner) — pulls from pool (and resets), or constructs fresh if pool is empty.
override DisposeCore() — calls base.DisposeCore (which finishes the figure, OverwriteData's the path-geometry header, ShrinkToFit's the chunk into a final byte[] handed to _owner.Close, and sets _disposed=true), then clears _owner + the chunk-list reference, then publishes itself to the pool slot if empty.
File 2: src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ByteStreamGeometryContext.cs
* Constructor body (the initial MIL_PATHGEOMETRY header write) extracted into a private InitializePathGeometryHeader() so it can be re-run on reset.
* New `protected void ResetForReuse()` — clears all base fields (_disposed/_currChunkOffset/_chunkList/_currOffset/the three MIL_* structs/_currentPathFigureDataOffset back to -1/_currentPolySegmentDataOffset back to -1/_lastSegmentSize/_lastFigureSize) and then re-runs InitializePathGeometryHeader so the post-reset state matches a freshly-constructed instance.
* New `protected void DetachChunkListForPool()` — drops the chunk-list reference. Called from StreamGeometryCallbackContext.DisposeCore so the pooled context does not keep the StreamGeometry's _data byte[] (which after ShrinkToFit is _chunkList[0]) alive through the pool slot.
CORRECTNESS
===========
- Lifecycle: StreamGeometry.Open is the SOLE caller. Open is always paired with a using/Close synchronously inside the same call (Geometry.Parse via ParseStringToStreamGeometryContext's `using (context)` block; same shape for any other Open user — there is no async or stored-context pattern). So the pool slot turns over within one method call.
- Reentrancy: nested Geometry.Parse on the same thread (e.g. parser's Geometry.Parse triggering another Geometry.Parse via a callback) — the inner Open finds _pooled = null (because the outer Acquire took it) and allocates a fresh instance, which on inner Dispose finds _pooled occupied and drops itself for GC. Outer Dispose then finds _pooled = null (inner one was dropped) and pools itself. Net: no double-pooling, no nested-state corruption.
- DispatcherObject thread affinity: [ThreadStatic] guarantees pool slot is per-thread. The cached _dispatcher field was set on the construction thread (= the only thread that can ever access this slot). VerifyAccess inside IDisposable.Dispose passes.
- _disposed semantics: base.DisposeCore guards its body with `if (!_disposed)`. After base sets _disposed=true, my DisposeCore body STILL runs (pool the instance). On second Dispose without an intervening Acquire, base's body no-ops (_disposed already true), and my pool step skips because `_pooled` is already this instance (`if (_pooled is null)` is false). Acquire's ResetForReuse sets _disposed=false before returning, so the next user starts in a clean state.
- Chunk pool interaction: ShrinkToFit returns the original 2 KB chunk to the [ThreadStatic] _pooledChunk and replaces _chunkList[0] with the final compacted byte[]. After my DetachChunkListForPool clears _chunkList, the next Acquire's ResetForReuse → InitializePathGeometryHeader → AppendData re-acquires the 2 KB chunk from the same _pooledChunk slot. Same chunk-pool churn as today, just with a reused wrapper.
- VerifyApi (called by every public API) checks _disposed: ResetForReuse sets it false before returning to caller, so the post-Acquire BeginFigure/LineTo/etc. calls succeed.
- GC.SuppressFinalize in IDisposable.Dispose: StreamGeometryCallbackContext / ByteStreamGeometryContext / DispatcherObject have no finalizers, so SuppressFinalize is a no-op. Repeated calls are harmless.
EXPECTED MICROBENCH IMPACT
==========================
- ParseCorpus: expected alloc Δ ≈ -12,000 B/op (110,688 → ~98,500 if AbbreviatedGeometryParser stays stack-allocated; if it does NOT, slightly more). Above the 16 B/op meaningful floor by ~750x.
- ParseCorpus: expected time Δ ≈ neutral. Acquire's pool-hit branch is ~3 instructions (load _pooled, compare null, store null+set _owner+ResetForReuse), versus the original `new StreamGeometryCallbackContext(this)` which does an alloc + ctor + InitializePathGeometryHeader. The reset path skips the alloc/ctor but adds ~12 field stores; net should be roughly even or slightly faster. The bench's 245 µs/op CV is ±500 ns stderr so any few-cycle delta is noise.
- No CPU regression risk: the hot loops inside ByteStreamGeometryContext (AppendData / GenericPolyTo / FinishFigure) are byte-for-byte unchanged.
…the FrugalStructList<byte[]> SingleItemList store across the StreamGeometryCallbackContext [ThreadStatic] pool cycle by replacing `_chunkList = default` with `_chunkList.Clear()` in both ResetForReuse and DetachChunkListForPool — eliminates the per-Geometry.Parse `new SingleItemList<byte[]>()` (~32 B/path × 100 paths = ~3.2 KB/op) allocation that survives iter=032's wrapper-pooling KEEP.
Filter pick
-----------
Cool list this iter: [*CultureContext*] (rows 28+29 both REJECT-UNCLEAR within last 2). Eligible filters with non-null bdn_filter, non-WindowLifecycle:
*ExceptionWrapper* alloc=2.40% (highest by profile.json)
*DispatcherInvokeAction* alloc=0.00%
*HwndWin32* alloc=0.00%
*GeometryParser* alloc=0.00% in profile (but bench measures non-zero; just landed iter=032 KEEP)
*Smoke* control
Per the program.md "prefer entries whose bdn_filter covers benchmarks that show a non-zero `Allocated` column" qualifier:
- *ExceptionWrapper* benchmark surface is alloc-clean: TryCatchWhenAction baseline ≈0 B/op, TryCatchWhenDoc baseline ≈24 B (the harness's own int-box from `object state = _index;`, NOT a wrapper allocation we can kill from the WindowsBase side). All 4 prior ExceptionWrapper attempts (rows 1, 4, 11, 16) showed `alloc Δ +0` because there's nothing to move; the most recent (iter=017 trycatchwhen-handinline-hotpath, row 16) post-mortem explicitly noted that further iters on this filter are time-axis-only and below the harness's effective resolution. Skipping despite the highest profile alloc score because the bench cannot expose changes there.
- *HwndWin32* baseline alloc was killed 40→0 by iter=026 (row 24 KEEP), so its bench surface is now also alloc-clean.
- *DispatcherInvokeAction* baseline alloc has always been 0 in the bench (row 2 saw +0; rows 10, 15, 25 same), so it's a time-axis-only target and on the time floor.
- *GeometryParser* ParseCorpus baseline is currently 93088 B/op (post iter=032 wrapper kill; pre-iter=032 was 110688). The *only* eligible filter with a measurable, non-zero baseline alloc on a hot-path-attributable code path. Picking it.
Hot path target
---------------
profile.json entry "(benchmarked) Geometry.Parse()" with bdn_filter=*GeometryParser*. Per-path alloc breakdown after iter=032:
- StreamGeometry instance: ~80 B REQUIRED (return value, can't kill)
- Final byte[] from ShrinkToFit: 700-900 B REQUIRED (owned by StreamGeometry)
- StreamGeometryCallbackContext wrapper: 0 already pooled in iter=032
- SingleItemList<byte[]> backing FrugalStructList<byte[]>._chunkList: ~32 B/path
- AbbreviatedGeometryParser instance: 0 already JIT-stack-allocated (iter=004 evidence)
The 32 B/path × 100 paths = 3200 B/op SingleItemList alloc is the next layer after the wrapper kill. Above the 16 B/op meaningful floor by 200x.
Why this allocation survives iter=032
--------------------------------------
iter=032's StreamGeometryCallbackContext.DisposeCore calls DetachChunkListForPool which sets `_chunkList = default;`, dropping the entire FrugalStructList<byte[]> contents — both the byte[] reference (correct: it's owned by the StreamGeometry, the pooled context must not pin it) and the underlying SingleItemList<byte[]> wrapper (incorrect: this is a generic container with no per-parse identity, safe to reuse).
When the next Acquire calls ResetForReuse → InitializePathGeometryHeader → AppendData, the AppendData first-write branch hits `_chunkList.Count == 0 → _chunkList.Add(chunk)`. FrugalStructList.Add's hot path:
if (_listStore is not null) { ... }
else { _listStore = new SingleItemList<T>(); }
With `_listStore == null` after the prior `default` reset, every parse re-allocates the SingleItemList.
The change
==========
Two one-liner edits in src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ByteStreamGeometryContext.cs:
ResetForReuse: `_chunkList = default;` → `_chunkList.Clear();`
DetachChunkListForPool: `_chunkList = default;` → `_chunkList.Clear();`
FrugalStructList.Clear() = `_listStore?.Clear();` — null-checks then calls SingleItemList.Clear which does `_loneEntry = default(T); _count = 0;`. The struct's `_listStore` field is preserved across the pool cycle, so the next AppendData's first Add reuses the existing SingleItemList instead of allocating a fresh one.
Both call-sites are paired (DetachChunkListForPool runs before pool, ResetForReuse runs after pull-from-pool); the ResetForReuse Clear is defense-in-depth — DetachChunkListForPool's Clear under normal flow already left _count=0, so this Clear is a no-op-ish (one null-check + 12 byte-store).
Behavior preservation
---------------------
- Lifecycle: StreamGeometry.Open is the SOLE caller of StreamGeometryCallbackContext.Acquire, and Open is always paired with synchronous using/Close inside the same call (Geometry.Parse via ParseStringToStreamGeometryContext's `using (context)` block). Pool slot turns over within one method call. The SingleItemList is part of the pooled context, lives only as long as the [ThreadStatic] slot — no additional pin.
- Single-chunk path (common case for the 100-path bench corpus): `_chunkList.Add(chunk)` from AppendData uses _listStore.Add → SingleItemList.Add which sets `_loneEntry = chunk; _count = 1;`. ShrinkToFit's `if (_chunkList.Count == 1)` branch sets `_chunkList[0] = buffer;` (in-place SingleItemList.SetAt). After CloseCore + DetachChunkListForPool, _loneEntry is null again, _count=0. Same SingleItemList survives to the next parse.
- Multi-chunk path (rare; only fires for parses larger than the initial 2 KB chunk): SingleItemList promotes to ThreeItemList → SixItemList → ArrayItemList in FrugalStructList.Add's else-branches. ShrinkToFit's else branch (line 482-484) does `_chunkList = new FrugalStructList<byte[]>(); _chunkList.Add(buffer);` which allocates a fresh SingleItemList for the final 1-chunk state. Post-Dispose, _chunkList is back to a SingleItemList — pool clears it, next parse reuses.
- DispatcherObject thread affinity: [ThreadStatic] guarantees per-thread pool. SingleItemList is a sealed class with no thread state. Cleared SingleItemList has the same observable state as a fresh `new SingleItemList<byte[]>()` (both have _loneEntry=null, _count=0, no _listStore in their own state). Add behaves identically.
- _disposed semantics, GC.SuppressFinalize, chunk-pool interaction: unchanged. _chunkList.Clear is purely a wrapper-state reset, doesn't touch the underlying byte[] (already either owned by StreamGeometry post-ShrinkToFit or returned to ByteStreamGeometryContext._pooledChunk).
- Public surface: ByteStreamGeometryContext is internal; ResetForReuse and DetachChunkListForPool are protected; called only from StreamGeometryCallbackContext (same assembly). No public-API change.
- FrugalStructList<T>.Clear is null-safe (guards on `_listStore?`), so calling it on a default-initialized struct is fine — covers the very-first-Acquire-of-process case where the cached context is a freshly-constructed instance with `_chunkList = default`.
Files changed
-------------
- src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ByteStreamGeometryContext.cs
Two `_chunkList = default;` → `_chunkList.Clear();` swaps + comment updates.
Expected microbench impact
--------------------------
- ParseCorpus alloc: expected Δ ≈ -3200 B/op (93088 → ~89888). Above the 16 B/op meaningful floor by 200x. Should land as a clear KEEP on the alloc axis.
- ParseCorpus time: expected Δ ≈ neutral or slightly negative. Eliminating the SingleItemList ctor saves ~10-15 ns per parse (alloc + ctor body); 100 paths = 1-1.5 µs/op. Below the bench's recent ±945 ns time-axis CV but possibly above its 5 ns/op meaningful floor across an op (-1000 ns is meaningful). The decision rule disqualifies it as a time-axis KEEP only if CIs overlap; either way the alloc Δ alone is enough to KEEP.
- No CPU regression risk: _chunkList.Clear is one null-check + 1-2 stores; AppendData / ShrinkToFit / DisposeCore inner loops are unchanged.
Risk
----
Low. The change is two line edits that swap one explicit-zero for an existing well-tested public method on the same field type. SingleItemList.Clear has been the canonical "reset without realloc" path for 20 years. The only path that depends on `_chunkList` post-DetachChunkListForPool is ResetForReuse → AppendData, which is unaffected by whether _listStore is null or a cleared SingleItemList (both make Count==0 and Add succeeds).
Next-iter pointer if this lands
-------------------------------
If KEEP at -3200 B/op, the remaining alloc surface on ParseCorpus is dominated by the per-path REQUIRED byte[] (700-900 B/path × 100 = ~80 KB) which can't be killed without changing StreamGeometry's storage contract. Any further alloc kills will be small (≤ 2-3 KB/op) — candidates: the IFormatProvider field on the parser if heap-allocated, the chunk pool primary 2 KB chunk if it's not actually pooling (re-verify ByteStreamGeometryContext._pooledChunk hot path), or the parser itself if iter=004's stack-alloc assumption is wrong on this newer JIT version. None obviously juicy enough to dominate over time-axis attempts.
If REJECT-UNCLEAR (alloc Δ +0 because Clear vs default surprise), the pool surface IS getting reused but FrugalStructList.Add isn't taking the _listStore-not-null branch — that would mean the `_listStore` field really is being lost between cycles via some path I missed (e.g. `_chunkList = new FrugalStructList<byte[]>()` somewhere I didn't find). Diagnostic next iter: scoped grep for any other `_chunkList =` write.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…: pool the AbbreviatedGeometryParser sealed-class instance via a per-thread [ThreadStatic] single-slot pool, mirroring iter=032's StreamGeometryCallbackContext pool. Parsers.cs:307 (PathFigureCollection) and ParsersCommon.cs:153 (Geometry.Parse hot path) currently allocate one fresh AbbreviatedGeometryParser per call (sealed class with ~96 B of fields: 3 refs, 3 Points = 16 B each, 2 ints, 1 char, 1 bool — plus object header). On the GeometryParser microbench, 100 paths/op × ~96 B = ~9.6 KB/op of avoidable per-call class allocation that survives both prior pool-style KEEPs (iter=032 wrapper, iter=033 SingleItemList store).
Hypothesis: pooling the parser instance kills the ~9.6 KB/op AbbreviatedGeometryParser class allocation, dropping the bench's per-op alloc from the iter=033 baseline of 89888 B/op to ~80000 B/op. Time delta is expected to be ~0 (the pool acquire is one [ThreadStatic] read + null compare + write; ReleaseToPool is three null assignments + null compare + conditional write — both cheaper than the new + ctor it replaces). Predicted alloc Δ ≈ -9600 B/op; predicted time Δ ≈ -50 ns/op (the elided class allocation should also drop GC pressure across the 100-path loop).
Plan / mechanics:
- ParsersCommon.cs AbbreviatedGeometryParser: add [ThreadStatic] static field s_pooled, plus internal static Acquire() / instance ReleaseToPool(). Acquire returns the slot (clearing it) or allocates fresh. ReleaseToPool nulls the three ref fields (_pathString, _context, _formatProvider) — value-type fields are unconditionally overwritten by ParseToGeometryContext at entry, so resetting them is wasted work — and publishes back if the slot is empty.
- ParsersCommon.cs:153 (ParseStringToStreamGeometryContext, called from ParseGeometry → Geometry.Parse): replace `new AbbreviatedGeometryParser()` with `Acquire()` + try/finally { ReleaseToPool() }. The try/finally is free in the no-throw case and ensures the parser still returns to the pool when ParseToGeometryContext throws ThrowBadToken (unbalanced state at throw is harmless because the next ParseToGeometryContext fully overwrites every field).
- Parsers.cs:307 (ParsePathFigureCollection): identical replacement (pool is shared across both call sites because the static slot is per-thread regardless of caller).
Files modified:
- src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ParsersCommon.cs (add pool slot + Acquire/ReleaseToPool; convert call site at line 153)
- src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/Parsers.cs (convert call site at line 307)
No public API surface change — AbbreviatedGeometryParser is `internal sealed class` and Acquire/ReleaseToPool are also internal.
Why this is alloc-axis-strategic:
- *GeometryParser* is the only filter currently producing reproducible alloc deltas (iter=032: -17600 B/op KEEP; iter=033: -3200 B/op KEEP). Compounding wins on the same lever.
- Profile lists Geometry.Parse / parser hot paths at alloc_pct_total ~0% on the startup trace, but the BENCH itself has 89888 B/op of measurable allocation surface — the parser is the cheapest +highest-confidence place to harvest alloc on the loop right now.
- The cool-list shows *CultureContext* on cooldown; *ExceptionWrapper* / *DispatcherInvokeAction* both report 0 B/op at the BDN layer despite non-zero ETW alloc, so the alloc axis isn't measurable for those filters. *HwndWin32* already had its 40 B/op drained by iter=026.
…geometry.FillRule = fillRule` in `if (fillRule != FillRule.EvenOdd)` inside ParseGeometry. ParseStringToStreamGeometryContext only assigns fillRule = Nonzero on paths starting with "F1"; every M-/m-prefixed path leaves fillRule at its initialized FillRule.EvenOdd, which IS the FillRuleProperty registered default. The unconditional setter routes through DependencyObject.SetValueInternal (allocates / mutates an EffectiveValueEntry to record the explicit set, runs IsFillRuleValid validation, dispatches FillRulePropertyChanged) for what is semantically a no-op against a freshly-constructed StreamGeometry. Skipping the call kills that per-Parse property-store work + alloc on the GeometryParser microbench (100 paths/op, all M-prefixed → 100/100 hit the skip). Targets the alloc axis of the GeometryParser microbench (current candidate baseline ~79.5 KB/op after iters 31/32/33 closed out the Open() wrapper, the SingleItemList<byte[]> store, and the AbbreviatedGeometryParser sealed-class instance). Expected alloc Δ: -8 to -32 B/path × 100 paths/op = -0.8 to -3.2 KB/op (depends on whether SetValue stores an EffectiveValueEntry on default-equal-default sets — in WPF DependencyObject the explicit-set flag is recorded even when the value already matches the registered default, so the entry is allocated). Expected time Δ: -50 to -300 ns/path × 100 paths/op (2-15% relative on the ~215 µs/op baseline). Single file changed: - src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ParsersCommon.cs (one conditional + WHY comment) Semantics preserved: a freshly-constructed StreamGeometry's FillRule already reads as EvenOdd via the DP system (the registered default in Generated/StreamGeometry.cs:180 is FillRule.EvenOdd), so omitting the SetValue when fillRule == EvenOdd leaves the next GetValue returning the same value the unconditional setter would have produced. The "fillRule was explicitly set" bit in the property store does flip true under the original code, but no observable consumer (Bounds, GetPathGeometryData, MayHaveCurves, the DUCE marshaling path, GeometryConverter.ConvertTo, Clone) depends on the IsExplicitlySet bit for FillRule — they all just read GetValue. The Nonzero branch is unchanged: when the path starts with F1, fillRule diverges from EvenOdd and the original SetValue call still runs.
…rt CulturePreservingExecutionContext.Run finally + CallbackWrapper culture writes from unconditional setter calls to ref-equals-guarded skips. Inline ReadCultureInfosFromCurrentThread / WriteCultureInfosToCurrentThread into Run + CallbackWrapper bodies, cache Thread.CurrentThread once at Run() entry, and short-circuit each `thread.CurrentCulture = X` / `thread.CurrentUICulture = X` write when the thread is already at the target culture. Targets the time axis of *CultureContext* / CpecCaptureAndRun now that iter=028 + iter=029 closed the alloc axis (88 → 64 → 0 B/op) and iter=030's plain Thread cache failed to register (the JIT intrinsic is already ~1-2 ns; the win must come from elsewhere). Filter: *CultureContext* (eligible — last 2 verdicts REJECT-UNCLEAR, REJECT-UNCLEAR; rows-since = 9, well past the 5-row cooldown threshold). Why ref-equals-skip beats unconditional set ------------------------------------------- CultureInfo.CurrentCulture's setter routes through AsyncLocal<CultureInfo>.set Value (modulo the thread-static fast path that fires only when no AsyncLocal has ever been assigned). AsyncLocal.set Value walks the current ExecutionContext's async-local map: it copies-on-write the IAsyncLocalValueMap, replaces or inserts the slot, and publishes the new EC via Thread.SetCurrentExecutionContext. That work fires every call regardless of whether the new value differs from the current one, because the setter has no short-circuit at the Value-equality level (the EC layer assumes any set is a real change). A reference-equality test on the existing thread.CurrentCulture vs. the value about to be written turns each redundant set into a property read + a ref-eq check. The dominant case for CPEC is precisely "no transition": Capture and Run on the same thread, no callback culture mutation, so $1 == $2 == $3 across the four set sites. The benchmark exercises this exact case (CpecCaptureAndRun: same-thread capture + run + noop callback) and so does every real WPF dispatcher dispatch where the producer queued an op from the dispatcher's own thread (true for self-Invoke, BeginInvoke -> Invoke chains, async/await on the dispatcher thread, Dispatcher.Yield, etc.). Set sites converted (4 in the steady-state path) ------------------------------------------------- 1. CallbackWrapper pre-callback: thread.CurrentCulture = _culture Skipped when _culture matches thread state. Same-thread Capture+Run case means EC.Run found no async-local culture diff and left the thread at the captured value, so this set was a no-op every cycle on the bench. 2. CallbackWrapper pre-callback: thread.CurrentUICulture = _uICulture Same reasoning. 3. Run finally: thread.CurrentCulture = _culture Skipped when EC.Run's own finally already restored to a matching value (i.e. the captured EC's culture flow matches the host culture, the common case for Capture-then-Run-on-same-thread). 4. Run finally: thread.CurrentUICulture = _uICulture Same reasoning. Field-write sites also gain a ref-eq skip (post-callback recapture in CallbackWrapper). When the callback does not modify culture — true for essentially every dispatcher operation, including all UI work, since explicit Thread.CurrentCulture mutation is rare — the pre/post values match by reference and the field writes are skipped, leaving only two property reads + two ref-equals on the recapture. Why iter=030's Thread.CurrentThread cache did not move the needle ----------------------------------------------------------------- iter=030 (cpec-thread-cache-and-inline-helpers) cached Thread.CurrentThread on a per-CPEC field so CallbackWrapper could skip its own TLS lookup. RU verdict, +5.69 ns mean — the reasoning was wrong: Thread.CurrentThread on .NET 6+ is a JIT intrinsic compiling to a single FS:[offset] load, so eliminating it saves ~1-2 ns per call site, dwarfed by the 5-10 ns property-setter cost that this iter targets. The Thread reference is still cached locally in this iter (cheap stack slot reuse, plus it serves as documentation), but the win comes from the setter-skip, not the TLS cache. Why iter=030's UNCLEAR is not predictive of this iter's UNCLEAR --------------------------------------------------------------- iter=030 saved at most ~3 ns/op (TLS hits eliminated). iter=028's KEEP showed CIs disjoint at -11.72 ns, so the harness has resolution to detect ~10 ns wins on this bench. With four AsyncLocal-backed setter calls collapsed to four property reads + four ref-equals (~5-10 ns each setter saved), the expected delta lands in the -15 to -30 ns range — comfortably above the meaningful threshold and within the disjoint-CI envelope demonstrated by iter=028. Behavioral parity ----------------- - When _culture matches thread.CurrentCulture: skipping the setter is a strict no-op. The thread remains at the same CultureInfo reference; no observable difference. - When _culture differs from thread.CurrentCulture: the setter fires as before. No semantic change. - When the callback mutates culture: post-callback ref-eq detects the change ($3 != $2), and the field writes fire as before. The Run finally then restores $3, which still differs from whatever EC.Run's finally left on the thread (=$1), so the setter fires there too. No semantic change. - ReferenceEquals on CultureInfo is the right test: CultureInfo instances are cached singletons per culture name (CultureInfo.GetCultureInfo / the static s_DefaultThreadCurrentCulture path), so ref-equality and value-equality coincide for the in-process culture flow. The path that produces a non- cached CultureInfo (CultureInfo.ReadOnly clones, customer subclasses) hits the ref-equality miss and takes the unconditional-set path, preserving prior behavior. Files modified -------------- - src/Microsoft.DotNet.Wpf/src/Shared/MS/Internal/CulturePreservingExecutionContext.cs Run(): cache Thread.CurrentThread once, snapshot capturedCulture/capturedUICulture, store on _culture/_uICulture inline (no helper). Finally block reads _culture/_uICulture into locals, ref-eq-guards the two thread setter calls. CallbackWrapper(): cache Thread.CurrentThread, read _culture/_uICulture into savedCulture/savedUICulture locals, ref-eq-guard the two thread setter calls (pre-callback restore), invoke callback, ref-eq-guard the two field writes (post-callback recapture). Removed unused private ReadCultureInfosFromCurrentThread / WriteCultureInfosToCurrentThread helper methods (their bodies are inlined into the two call sites that used them). Sub-agents used: none (single-file change, surface area too small to benefit). Expected delta -------------- - alloc Δ: +0 B/op (already at 0 post-iter=029). - time Δ: -10 to -25 ns/op on CpecCaptureAndRun. RawExecutionContextRun unaffected (does not touch CPEC). CIs should disjoint vs the 111 ns baseline given the demonstrated 5-6 ns CV. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…: collapse ReadWriteData's main while-loop into a straight-line "fits in current chunk" fast path for the dominant small-write case (16/24/40/48 byte AppendData of MIL_* structs and Points). Eliminates per-iteration Math.Min, two of three FrugalStructList indexer accesses, the inner cbDataForThisChunk>0 branch, and the post-iteration cbDataSize>0+currentChunk++ overflow handling. Replaces Marshal.Copy with fixed + Buffer.MemoryCopy (a JIT-recognized memcpy intrinsic, no per-call array-pinning P/Invoke transition). Slow path retained verbatim for chunk-crossing/grow correctness. Plus: LineTo's 1-element stackalloc replaced with &point direct-address pass-through. Filter: *GeometryParser* (eligible per cool-list.py — last 2 verdicts are REJECT-UNCLEAR / REJECT-UNCLEAR but rows-since=7 > 5 threshold; cooldown.json computed_at 09:17 lists *CultureContext* as the only cool filter). Pick rationale (alloc-axis priority overridden by signal-quality) ----------------------------------------------------------------- Per program.md, the alloc-axis is preferred when available — and *ExceptionWrapper* technically has the highest profile.json alloc_pct_total (4.414%) among eligibles. But the BDN GeometryParser bench has been the only filter that consistently registers detectable signal on this loop (KEEPs at iters 9, 20, 21, 22, 23 — geometry-* all landed wins, while the dispatcher-chain benches have all returned "noise, sub-floor" or "noise, meaningful" the past 10+ iterations). The ExceptionWrapperBenchmark per-op time (TryCatchWhenAction ~10 ns, TryCatchWhenDoc ~26 ns) is too small to register a 5+ns trim above its CV; HwndWin32 / DispatcherInvokeAction's cross-thread ~85µs/op dwarfs any few-ns dispatcher-fast-path win. GeometryParser's ~344,943 ns/op baseline + its low per-op CV (program.md operational note: "lower CV and zero baseline allocation") gives this filter the best chance of clearing the meaningful-time floor on a non-alloc change. Hot-path target --------------- Every Geometry.Parse drives ParseToGeometryContext through StreamGeometryCallbackContext (= ByteStreamGeometryContext via inheritance) → BeginFigure / LineTo / BezierTo / FinishFigure / FinishSegment, each of which calls AppendData and/or OverwriteData with byte sizes 16 (Point), 24 (MIL_SEGMENT_POLY), 40 (MIL_PATHFIGURE), or 48 (MIL_SEGMENT_ARC). On the GeometryParserBenchmark.ParseCorpus invocation: 100 paths × ~17 segments per path × ~2 AppendData calls per segment ≈ 3400 ReadWriteData calls per op. Both the "first chunk" path (AcquireChunkFromPool returns a default-sized byte array typically ≥ 1 KB) AND the typical "subsequent appends to the same chunk" path land entirely inside one chunk — chunk-crossing only happens at the chunk-grow boundary which is rare on the corpus's ~200-400 byte serialized output per path. Iter=043 (fb5d282, REJECT-UNCLEAR) made the same Marshal.Copy → Buffer.MemoryCopy swap inside the EXISTING loop structure and saw -10367 ns time delta tagged "noise, meaningful" — the change was directionally right but the loop framing (cbDataForThisChunk>0 branch + post-iter cbDataSize>0 handling + Math.Min + 3 indexer accesses) absorbed most of the savings in branch-predictable but still-not-free code. Iter=045 takes the same memcpy-intrinsic substitution but ALSO collapses the loop structure on the dominant single-chunk path so the fast path is straight-line code with one indexer load, one bounds compare, one fixed-block, one Buffer.MemoryCopy, and one bufferOffset update. Mechanics (fast path inside ReadWriteData) ------------------------------------------ Before: while (bufferOffset > _chunkList[currentChunk].Length) { /* skip */ } while (cbDataSize > 0) { int cbDataForThisChunk = Math.Min(cbDataSize, _chunkList[currentChunk].Length - bufferOffset); if (cbDataForThisChunk > 0) { Invariant.Assert(_chunkList[currentChunk] != null && ...); Marshal.Copy(_chunkList[currentChunk], bufferOffset, (IntPtr)pbData, cbDataForThisChunk); // or reverse cbDataSize -= cbDataForThisChunk; pbData += cbDataForThisChunk; bufferOffset += cbDataForThisChunk; } if (cbDataSize > 0) { currentChunk++; if grow ...; bufferOffset = 0; } } After: while (bufferOffset > _chunkList[currentChunk].Length) { /* skip — usually 0 iters */ } { byte[] chunk = _chunkList[currentChunk]; if ((uint)cbDataSize <= (uint)(chunk.Length - bufferOffset)) { if (cbDataSize > 0) { Invariant.Assert(chunk != null); Invariant.Assert(chunk.Length > 0); fixed (byte* pbChunk = chunk) { Buffer.MemoryCopy(pbChunk + bufferOffset, pbData, cbDataSize, cbDataSize); // or reverse } bufferOffset += cbDataSize; } return; } } /* slow-path while-loop kept verbatim for chunk-crossing/grow */ Per-call savings on the AppendData hot path: * 1 indexer load instead of 3 (`_chunkList[currentChunk]` was called for Length read, two assert reads, and the Marshal.Copy arg → now hoisted to `chunk` local once) * Math.Min eliminated (replaced by single `cbDataSize <= chunk.Length - bufferOffset` compare) * Inner `cbDataForThisChunk > 0` branch eliminated on the size>0 path (folded into outer `cbDataSize > 0`) * Post-iteration `if (cbDataSize > 0) { currentChunk++; ... bufferOffset = 0; }` eliminated entirely on the fast path * Marshal.Copy → Buffer.MemoryCopy via fixed: avoids the per-call array-pin + P/Invoke-style boundary cross that Marshal.Copy(byte[],int,IntPtr,int) pays internally; Buffer.MemoryCopy lowers to a JIT-intrinsic memcpy that uses optimal SIMD/REP MOVS for the target. * uint-cast on the fits-check converts a potentially negative `chunk.Length - bufferOffset` (post skip-loop with bufferOffset==chunk.Length is the boundary case) into a large unsigned value so the comparison fails cleanly and falls through to the slow path that handles chunk crossing. LineTo collateral fix --------------------- LineTo was using `stackalloc Point[1]` + assign + `GenericPolyTo(scratchForLine, 1, ...)`. C# permits taking the address of a value-type by-value parameter inside an `unsafe` block (locals/parameters of unmanaged type live on the stack and are non-movable, so they are "fixed variables" per the spec — no `fixed` block required). Replacing with `GenericPolyTo(&point, 1, ...)` skips the 1-element stackalloc setup and the explicit Point copy. Marginal but free. Estimated impact ---------------- Per-call savings for ReadWriteData on the fast path: ~10-15 ns out of ~25-35 ns prior. With ~3400 calls per ParseCorpus op, total savings ~34,000-51,000 ns on a 344,943 ns baseline → roughly -10 to -15% relative time delta. Comfortably above this bench's ~3,000 ns sub-floor and the 5 ns / 16 B meaningful threshold. Even if the Buffer.MemoryCopy intrinsic recognition was already happening through Marshal.Copy in .NET 10 (collapsing one half of the savings), the loop-structure collapse alone is ~5-7 ns × 3400 = ~17,000-24,000 ns ≈ 5-7% which still clears the floor. LineTo extra savings: ~2-3 ns/call × ~1500 LineTo calls = ~3,000-4,500 ns additional. Combined predicted Δ time: -7% to -16% on ParseCorpus. Predicted Δ alloc: 0 B/op (no allocation change; both `fixed` and `&point` are stack-only). Behavior preservation --------------------- - Fast path entry condition `(uint)cbDataSize <= (uint)(chunk.Length - bufferOffset)`: equivalent to the boolean "the entire write fits in the current chunk". When chunk.Length-bufferOffset≥0 (after the leading skip-loop with strict-greater exit), the uint cast is no-op semantically. When chunk.Length-bufferOffset==0 AND cbDataSize==0, the fast path enters, skips the inner copy-block (cbDataSize > 0 is false), and returns with bufferOffset unchanged — same observable as the original (which would not enter its while loop at all). When chunk.Length-bufferOffset==0 AND cbDataSize>0, fast path falls through (uint compare false) to slow path, which advances currentChunk and grows as before. - `cbDataSize == 0` early bail: original code's outer `while (cbDataSize > 0)` never enters, returning immediately; new fast path enters the outer compare (0 <= ANY non-negative), skips inner copy, and returns. Same observable. - `Marshal.Copy(byte[],int,IntPtr,int)` ↔ `Buffer.MemoryCopy(pbChunk+offset, pbData, n, n)`: equivalent for n bytes, both use platform memcpy under the hood. Same true for the reverse direction. - Multi-chunk crossing: handled by the slow path (kept verbatim modulo the same Marshal.Copy → Buffer.MemoryCopy substitution and the chunk hoist for consistency); chunk-grow path identical to before. - Asserts preserved: `chunk != null`, `chunk.Length > 0` retained on the fast path; `chunk.Length >= bufferOffset+cbDataForThisChunk` retained on the slow path (using the hoisted local). - LineTo `&point` semantics: GenericPolyTo's Point* arg is read for `count` bytes via `AppendData((byte*)points, sizeof(Point) * count)` then memcpy'd into the chunk; pin lifetime of the parameter local is the duration of the LineTo method call, which encloses GenericPolyTo's full execution. No GC race. Files changed ------------- - src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ByteStreamGeometryContext.cs - LineTo (line ~152): `&point` direct address-of, removes 1-element stackalloc. - ReadWriteData (line ~524): adds straight-line "fits in chunk" fast path before the existing while-loop; both fast and slow paths use `fixed` + Buffer.MemoryCopy instead of Marshal.Copy; the slow path also hoists the `_chunkList[currentChunk]` indexer to a local for consistency with the fast path. Path-allowlist check: only PresentationCore touched; no Shared/, WindowsBase/, System.Xaml/, PresentationFramework/. Risk ---- The closest prior attempt is iter=043 (Marshal.Copy → Buffer.MemoryCopy + indexer hoist, REJECT-UNCLEAR -10367 ns "noise, meaningful"). The meaningful difference here is the loop-structure collapse, which removes per-call branch overhead the iter=043 change preserved. If iter=045 also returns REJECT-UNCLEAR, the next-iter pointer is to step back from this hot path entirely and look at the parser-side ParseToGeometryContext outer loop (ReadToken + switch dispatch, ~1500 invocations per op) where switch-hoist or command-specialized inner loops have not yet been tried in earnest. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…lapse the integer fast path in AbbreviatedGeometryParser.ReadNumber from two digit walks to one — accumulate the int value during the same walk that advances _curIndex past the digit run, eliminating the post-hoc fold loop in the simple-integer return block.
Filter: *GeometryParser* — eligible (cool-list.py: empty cool list, last 2 verdicts on this filter were KEEP (iter=045 readwritedata-fits-in-chunk-fastpath) and REJECT-UNCLEAR (iter=046 appenddata-currentchunk-cache); no cooldown.
Pick rationale
==============
profile.json TIME-axis filters all eligible. ALLOC axis is ≈0 baseline across every benchmark in the harness now (CultureContext, ExceptionWrapper, HwndWin32 — all wrappered/pooled to 0; GeometryParser stable around 73888 B/op since iter=035). For benches where alloc baseline is 0, time is the only available signal — and *GeometryParser* has the cleanest of those (single ParseCorpus method, ~284k ns/op headroom, lowest CV per the operational note, only filter that has banked a TIME-axis KEEP this week including iter=045's -61287 ns). DispatcherInvokeAction / HwndWin32 / ExceptionWrapper all measure on STA helper threads where the BDN MemoryDiagnoser misses the actual allocation site and time CV is dominated by ~1-3 ns/op cross-thread signaling.
Hot-path target
===============
The *GeometryParser* corpus is 100 paths × 8-24 segments × 2-6 numbers per segment → ≈4000 ReadNumber invocations per ParseCorpus op, all positive 1-3 digit integers (rnd.Next(0,1000)). That puts every single ReadNumber call on the simple-integer fast path (no '.', no 'E', no 'I'/'N', no negative sign, no overflow into 9+ digits). The current implementation walks each digit run TWICE on this path:
1. SkipDigits(!AllowSign): walks digits, advances _curIndex.
2. The post-hoc loop in the simple-int return block (lines 533-537 of the original):
int value = 0;
while (start < end) { value = value * 10 + (s[start] - '0'); start++; }
— re-walks the SAME digit chars to compute the int value.
Both walks read s[i] (string indexer with bounds check + null check) per char and increment a position. Merging them into one pass removes one indexer load per digit. For 1-3 digit corpus numbers and ~4000 ReadNumber calls, that is ≈8000-12000 fewer indexer loads per op.
Why retry now
=============
A previous attempt at this idea was REJECTed at iter=021 (commit c06efcb, results row 21) with `alloc regressed: 0 → 110688 B/op`. That verdict is unexplained — 110688 is precisely the pre-iter=032 ParseCorpus alloc baseline, before the StreamGeometryCallbackContext / FrugalStructList / parser-instance pools landed (iters 32-35). The diff at iter=021 has no measurable allocation contribution on review (no boxing, no closure, no extra exception path), and double-checking every input shape (M/L corpus, "+5", "-5", ".5", "1.0", "1e5", "Infinity", "-NaN", 8-digit int, 10-digit int) shows bit-identical observable behavior to the original. Most plausible explanation: a measurement-side artifact at the time (iter=021 ran 16:37, the harness all-3-DLL-swap fix landed iter=013 at 14:34 but the publish-dir reset between iters was still being shaken out across 14:30-17:30; the 110688 number does not match anything iter=021 itself could have introduced). Refreshed harness, parser-instance pool stable since 20:49, and the same corpus has banked four other GeometryParser KEEPs since (iters 32-35 + 045) without re-encountering the 110688 ghost.
The change
==========
ReadNumber's else-branch (no Infinity, no NaN — i.e. the integer-or-decimal path):
Before:
SkipDigits(!AllowSign); // walk only
if (More() && _pathString[_curIndex] == '.') { simple = false; _curIndex++; SkipDigits(!AllowSign); }
if (More() && (...'E' or 'e')) { simple = false; _curIndex++; SkipDigits(AllowSign); }
After:
{
string s = _pathString;
int end = _pathLength;
int i = _curIndex;
while (i < end)
{
uint d = (uint)(s[i] - '0');
if (d > 9u) break;
intValue = intValue * 10 + (int)d;
i++;
}
_curIndex = i;
}
if (More() && _pathString[_curIndex] == '.') { simple = false; _curIndex++; SkipDigits(!AllowSign); }
if (More() && (...'E' or 'e')) { simple = false; _curIndex++; SkipDigits(AllowSign); }
The simple-integer return collapses from a 16-line block (re-walk + sign-scan) to one line:
return (first == '-') ? -intValue : (double)intValue;
`first` is the original _token captured at method entry (the IsNumber-loaded first char before any sign skip). Sign was already consumed at line 466-469. intValue holds the pure-magnitude accumulation; on the only relative path (negative leading sign) we negate. Original code re-read s[start] inside the simple-int block and applied a `value * sign` multiply; this is identical mathematically and one fewer load + one fewer multiply.
Behavior preservation
---------------------
Walked through every input shape manually:
- "5" → first='5'; walk 1 digit, intValue=5; gate (1≤8) true → return 5. ✓
- "999" → first='9'; walk 3 digits, intValue=999; gate true → return 999. ✓
- "+5" → first='+'; sign-skip _curIndex; walk '5', intValue=5; gate _curIndex-start=2≤8 true → return 5. ✓
- "-5" → first='-'; sign-skip _curIndex; walk '5', intValue=5; gate true; (first=='-') → return -5. ✓
- ".5" → first='.'; no sign-skip; walk loop sees '.' (d>9u) breaks immediately, intValue=0; '.' branch fires → simple=false; SkipDigits walks '5'; slow path → double.Parse(".5") = 0.5. ✓
- "1.5" → first='1'; walk '1', intValue=1, breaks on '.'; '.' branch fires → simple=false, SkipDigits walks '5'; slow path → double.Parse("1.5") = 1.5. ✓
- "1e5" → first='1'; walk '1', intValue=1, breaks on 'e'; '.' branch skipped; 'e' branch fires → simple=false, SkipDigits walks '5'; slow path → double.Parse("1e5") = 100000. ✓
- "Infinity" → first='I'; sign-skip skipped (first not '+'/'-'); 'I' arm fires → _curIndex+=8, simple=false; slow path → double.Parse("Infinity") = ∞. ✓
- "-Infinity" → first='-'; sign-skip _curIndex; More()&&'I' → arm fires → _curIndex+=8, simple=false; slow path → double.Parse("-Infinity") = -∞. ✓
- "NaN" → first='N'; 'N' arm fires → _curIndex+=3, simple=false; slow path → double.Parse("NaN") = NaN. ✓
- "12345678" → first='1'; walk 8 digits, intValue=12345678; gate _curIndex-start=8≤8 true → return 12345678. ✓
- "+12345678" → first='+'; sign-skip; walk 8 digits; _curIndex-start=9 → gate false → slow path → double.Parse("+12345678") = 12345678. ✓ (Identical to original's slow-path entry.)
- "123456789" → first='1'; walk 9 digits, intValue=123456789 (still fits int32, no overflow); _curIndex-start=9 → gate false → slow path → double.Parse → 123456789.0. ✓
- "9999999999" → first='9'; walk 10 digits, intValue overflows mid-loop (wraparound, not throw) but gate _curIndex-start=10 false → slow path → double.Parse → 9.999999999E9. ✓ (Overflow is benign because intValue is discarded before being read.)
Slow-path contract: the lexeme passed to double.Parse is _pathString.AsSpan(start, _curIndex - start). `start` is captured BEFORE the sign skip (line 455), so the span includes the sign. _curIndex advances past sign + Infinity/NaN/digits/decimal/exponent identically in both the new and the old code. double.Parse output is therefore bit-identical.
Files modified
==============
src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ParsersCommon.cs
~ ReadNumber: replaced first SkipDigits + post-hoc fold loop with a
single walk-and-accumulate; simple-integer return collapsed to a
sign-conditional negate. The `.` and `E`/`e` slow-path branches and
the Infinity/NaN arms are unchanged.
Expected microbench impact
==========================
- ParseCorpus: time Δ ≈ -10000 to -25000 ns/op (≈ -3.5% to -8.5% of the
~284k baseline). Lower bound (≈ ½ a digit-walk × 4000 numbers × ~3 digits)
is ≈12000 ns; upper bound (full 1-indexer-load saved per digit, plus the
cumulative effect of dropping the second-walk loop's branch overhead) is
≈25000 ns. The 5 ns/op meaningful-time threshold and the ~3000 ns
sub-floor noise observed on this bench (iters 7/8/14/22) are both
comfortably below.
- ParseCorpus: alloc Δ = 0 B/op. No new allocations: walk-loop is purely
stack ints + indexer reads; the slow path's double.Parse + exception
surface is byte-identical to the original.
- Risk: the iter=021 ghost — if alloc again comes back as +110688, the
suspect is the harness pinning publish-dir state between iters (cooldown
protection should already exclude this filter for 5 rows from the next
REJECT-UNCLEAR if that recurs). If the time delta is REJECT-UNCLEAR
(sub-floor), the next iter should pivot to the per-segment
FinishSegment / GenericPolyToHelper overhead — the only remaining
per-LineTo/per-BezierTo work the iter=045 fast path did not absorb.
…: hoist `s/end/i` locals across the entire ReadNumber body and capture the digit-walk's terminating char into a local `endChar`, so the period and exponent post-walk checks compare a register instead of re-reading `_pathString[_curIndex]` via More()+indexer pairs. Also pre-empt the I/N detection off `_token` (already in a register) for unsigned-prefix numbers, eliminating two More()+indexer reads on the dominant unsigned-integer path. Inline the two SkipDigits call sites (period + exponent) so the inner walks reuse the same s/end/i locals; SkipDigits had no other callers and is removed.
Hypothesis: the previous structure forced a `_curIndex = i;` write between each sub-walk (digit run -> period scan -> exponent scan -> SkipDigits-internal hoist), and each post-walk guard re-read `_pathString[_curIndex]` via More() + an indexer load. On the GeometryParser corpus (100 paths, ~4500 ReadNumber calls per ParseCorpus, all unsigned integers) the period and exponent branches always short-circuit; the existing structure spends those two short-circuit evaluations on field reloads rather than register comparisons. Capturing `endChar` from the integer walk's terminating iteration converts both post-walk checks into register-resident compares, and pre-empting I/N off `_token` removes another two More()+indexer pairs from the unsigned dominant path.
Expected time Δ: ~-5 to -15 µs/op (current GeometryParser KEEP floor is ~247 µs/op after iter=047; this trims ~5 instructions × 4500 calls = ~22500 instructions on the integer-only fast path). Expected alloc Δ: 0 (the path is already alloc-free post-iter=039). Worst case: REJECT-UNCLEAR if the JIT was already keeping `_curIndex` in a register across the original sub-walks.
Files modified:
src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ParsersCommon.cs
- Replaced AbbreviatedGeometryParser.ReadNumber body with hoisted-local +
endChar-capture form. Period and exponent guards now read endChar (a
local) instead of doing More() + _pathString[_curIndex] pair-reads.
I/N pre-empt uses `_token` (= `first`) for unsigned numbers.
- Removed SkipDigits (no callers remaining; inlined into the two
ReadNumber sub-walks).
- Tidied a stale comment in SkipWhiteSpace that referenced SkipDigits.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ark `More`, `SkipWhiteSpace`, `IsNumber`, and `ReadToken` in AbbreviatedGeometryParser with `[MethodImpl(MethodImplOptions.AggressiveInlining)]` so the JIT can collapse the per-number prelude (SkipWhiteSpace + IsNumber) and the `while (IsNumber(...))` loop tests into the surrounding ReadNumber and ParseToGeometryContext bodies — killing two method-call frames on the dominant ReadNumber hot path and one frame on every loop test. Filter: *GeometryParser* (eligible — last 2 verdicts KEEP (dotnet#48 endchar-fullhoist), REJECT-UNCLEAR (dotnet#46 parsetogc-hoist-inner-switch reverted, then dotnet#47 readnumber-singlepass-int-retry KEEP, then dotnet#48); cool list at iter start: empty per cooldown.json computed_at 10:52). GeometryParser is the productive holdover filter; the orchestrator's operational note authorizes it explicitly ("+ GeometryParser holdover") and it has been the only filter delivering KEEPs in the last 5 tier-B iters. Hot-path target --------------- The benchmark corpus (100 paths, ~17 segments each, only M/L/C with unsigned int coords) drives ~5000 ReadNumber calls + ~1700 IsNumber-as-loop-test calls + ~1700 ReadToken calls per ParseCorpus. Each of these calls today pays an out-of-line method-call frame that the JIT does not reliably inline despite the methods being modestly sized (More ~5 IL, IsNumber ~50 IL, SkipWhiteSpace ~80 IL, ReadToken ~20 IL). The ReadNumber prelude is `if (!IsNumber(allowComma)) ThrowBadToken();` which calls IsNumber → SkipWhiteSpace. That's two method-call frames stacked on the hot path of every parsed number. After the digits walk, control returns to the caller (ReadPoint or the cmd switch), then the do-while's `while (IsNumber(AllowComma))` test pays another frame. Per-iter savings target: ~3-5 ns × {5000 (ReadNumber prelude) + 1700 (loop test)} = 20-33 µs per ParseCorpus. Baseline after iter=048 is ~150 µs/op (149,957 ns), so the target delta is 13-22% relative. CV on this benchmark is well under 5% (recent KEEP CIs at -38388 ns and -6513 ns landed cleanly), so a 20+ µs delta should clear the disjoint-CIs bar. Why this is testable now (and wasn't at iter=015) -------------------------------------------------- iter=015 (geometry-skipws-fastpath-noskip, REVERTED) added the same three AggressiveInlining hints PLUS a fast-path skip in SkipWhiteSpace that returned early without updating `_token`. That fast path was a correctness landmine — IsNumber's body reads `_token` after SkipWhiteSpace returns, so the staleness would have made IsNumber report wrong results on the second consecutive call. The verdict was REJECT-UNCLEAR with time Δ -15409 ns (genuine improvement, but below the 99.9% CI margin at the time when the baseline was ~230 µs). This iter is strictly the inlining hints — no body changes, no fast-path skip, no semantic shift. With the baseline now ~150 µs (post iter=047/048 wins), the same magnitude of -10 to -20 µs/op delta becomes a 7-13% relative win, which is enough to cross the disjoint-CIs threshold the harness uses for KEEP. (iter=015's -15 µs was sub-floor at the higher baseline; here it should clear.) The change ========== 1. Add `using System.Runtime.CompilerServices;` (sibling files in this directory already use it; no new dependency). 2. `[MethodImpl(MethodImplOptions.AggressiveInlining)]` on: - `More()` (5 IL — trivially inlinable but the attribute is needed because More is called inside SkipWhiteSpace, which itself is being marked Inline; without the inner-most More attr the JIT may decline to fold More into the inlined SkipWhiteSpace body) - `SkipWhiteSpace(bool)` (~80 IL — at the AggressiveInlining budget but still inlinable; the JIT has been observed to inline ~120 IL bytes with this hint) - `IsNumber(bool)` (~50 IL — comfortably inlinable) - `ReadToken()` (~20 IL — trivial) No body edits; the methods' semantics are 100% preserved. Only a `using` directive and four attribute lines change. Behavior preservation --------------------- - AggressiveInlining is a hint, not a contract; the JIT may still decline to inline if a caller's combined IL exceeds an internal budget. Worst case is no-op (no behavior change, no perf change). - Inlining changes no observable behavior — exception throw points, side effects, and field writes happen at the same logical sequence relative to the caller. - The methods are private and called only from within AbbreviatedGeometryParser (ReadToken, ReadBool, ReadNumber, ParseToGeometryContext); no external callers depend on these being out-of-line. Files changed ------------- - src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ParsersCommon.cs: * +1 using System.Runtime.CompilerServices; * +4 [MethodImpl(MethodImplOptions.AggressiveInlining)] attributes (one per method noted above) * Inline comments documenting why AggressiveInlining is appropriate at each site. Expected microbench impact (GeometryParserBenchmark.ParseCorpus) --------------------------------------------------------------- - expected time Δ: -10 to -25 µs/op (7-17% relative). Above the ~3 µs CI margin observed in iter=047/048's KEEPs. - expected alloc Δ: 0 B/op (parser internals don't allocate on the hot path; baseline alloc is dominated by Geometry tree construction which is unchanged). Risk ---- - Modest: code-bloat at every IsNumber/SkipWhiteSpace call site. With ~5+ call sites in ParseToGeometryContext alone, the function may grow significantly. The JIT compiles bigger but executes fewer call frames; net win on hot loops. - If JIT was ALREADY inlining these (PGO or heuristics), the win evaporates and we land sub-floor. iter=015's data point suggests it was NOT — the -15 µs delta indicates real frame elimination. Sub-agents used: none (single-file mechanical attribute additions).
…ine): split ExceptionWrapper.TryCatchWhen into a no-handlers fast path that inlines two type-test dispatches (Action + DispatcherOperationCallback) and a NoInlining slow-path helper containing the catch-protected body. Removes the EH region from TryCatchWhen, allowing the JIT to honour the [AggressiveInlining] hint and fold the method into its caller (Dispatcher op-callback path; ExceptionWrapper benchmark dispatch). Cold paths tail-call the unmodified InternalRealCall to preserve the IL/JIT shape that prevents the NegativeControlDynamicInvoke regression seen in iter=012. This is the agent's iter-19 draft from the previous ralph session, committed by the orchestrator after the toolchain cutover (b9e827d). Measuring it under the new out-of-process shadow harness serves as the end-to-end validation that the new pipeline produces correct verdicts on a real product change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…hed): add a `_callbackTouchedCulture` bool to CulturePreservingExecutionContext and gate the entire post-EC.Run finally restore block on it. The bool is set by CallbackWrapper iff the post-callback recapture observed a culture change in the user callback (i.e. wrote a fresh CultureInfo into _culture or _uICulture). Reset to false by ReturnToPool so a pooled instance starts clean on the next Capture-Run cycle.
Hypothesis: in the dominant Capture-Run-Capture-Run dispatcher pattern (and in CpecCaptureAndRun's noop callback), the user callback never touches Thread.CurrentCulture / Thread.CurrentUICulture. After EC.Run terminates it has reverted thread state to the entry-time culture pair, and _culture / _uICulture still hold those same values (CallbackWrapper never wrote them back). The finally block's two ref-equals checks therefore both succeed and the property setters are skipped — but we still pay the two Thread.Current(UI)Culture property reads (each routes through CultureInfo.CurrentCulture's AsyncLocal<CultureInfo>.get_Value, which walks the EC async-local chain after .NET 4.6 even on a TLS-fast-path hit) plus two ref-equals comparisons and two field reads. Gating the whole block on a single byte-load + branch elides all of that on the dominant path.
Expected delta (CpecCaptureAndRun, post-iter=039 baseline ≈ 92 ns): time Δ ≈ -8..-20 ns / op (kills 2 Thread.CurrentCulture/UICulture property reads + 2 ref-equals + the conditional branches in the finally; field-read elimination is small but composes); alloc Δ +0 B/op (no new allocation, no boxing — bool field is part of the existing CPEC instance and fits in the existing 1-byte slot alongside _disposed without growing the object past its 64-byte cache line).
Why this is a fresh angle vs prior CultureContext attempts: iters 1/10/13/19 inlined fields, iter 7 added pool work, iter 20 went TLS-direct, iter 27/28/39 KEPT (CCM-inlining, threadstatic-pool, ref-equal skip on culture setter), iter 29/30 inline helpers, iter 40/41 cleanup/pool strip, iter 57 REJECTed an attempt to skip the *pre-callback* restore in CallbackWrapper (regression caused by 3 new state fields + complex bookkeeping). None of those attacked Run()'s finally block — they all targeted CallbackWrapper or Capture(). Mine targets the post-EC.Run epilogue, which is a separate hot region and which is wasted work in the dominant path. The Capture+Run baseline is ~92 ns and even an 8 ns cut clears the 5 ns time floor with margin, while the field-write side (which only fires on the rare callback-touched-culture path) does not regress the dominant case.
Files modified:
src/Microsoft.DotNet.Wpf/src/Shared/MS/Internal/CulturePreservingExecutionContext.cs
- add `private bool _callbackTouchedCulture` field with explanatory comment
- in CallbackWrapper post-callback recapture: set _callbackTouchedCulture = true alongside the existing _culture / _uICulture writeback (only on the rare path)
- in Run()'s finally: wrap the entire restore block (2 field reads + 2 thread property reads + 2 ref-equals + 2 conditional setters) in `if (executionContext._callbackTouchedCulture) { ... }`
- in ReturnToPool: reset the bool to false alongside the other field clears
No sub-agents used — single-file, single-mechanism change with clear semantics; design space already mapped from the prior 14 CultureContext iterations' commit history and the existing source comments.
Adds a struct-out internal method that returns the accumulated affine transform as a Matrix value, without ever allocating a MatrixTransform or wrapping in a GeneralTransform. Delegates to the existing TrySimpleTransformToAncestor (which is already alloc-free in the non-Effects, non-3D path). Profile of MotionCatalyst-cli (19 sec) attributed 480 MB MatrixTransform and 427 MB Matrix allocs to InternalTransformToAncestor — together ~32% of total app alloc. Caller adoption (AdornerLayer.UpdateElementAdorners) is a separate PresentationFramework change that will land alongside the allowlist re-enablement. This commit is additive (new internal method, no existing API touched); no caller change yet, so no measurable runtime delta until consumers switch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
UIElementHelper.InvalidateAutomationAncestors allocated a fresh Stack<DependencyObject> on every call. Profile of MotionCatalyst-cli (19 sec) attributed 94 MB to this single allocation. The walk is single-threaded (UI thread), bounded by the visual tree depth, and the stack is empty at entry and exit — qualifies for a [ThreadStatic] pooled instance. Defensive Clear() at entry guards against any unexpected residue. No reentrancy on the same thread (verified via grep over InvalidateAutomationAncestorsCore overrides). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Profile of MotionCatalyst-cli (19 sec) attributed ~572 MB combined to this single method: - 189 MB ArrayList (the per-call `new ArrayList(1)` removeList) - 194 MB Object[] (ArrayList's backing store) - 189 MB UIElement[] (the per-call `new UIElement[N]` keys snapshot on the element==null walk-all path) Replace both with reusable instance fields cleared at entry / exit. The removeList becomes a List<UIElement> (avoids the legacy ArrayList + Object[] boxing pair). The keys buffer grows-only with min capacity 8; slots are explicitly Array.Cleared after iteration to avoid retaining UIElement refs across calls. UpdateAdorner is UI-thread-only and not self-reentrant, so the single-instance pool is safe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
OnLayoutUpdated previously called UpdateAdorner(null) on every fire (~570/sec from MediaContext.RenderMessageHandler), regardless of whether any adorned element's layout actually changed. In quiescent UI states this is pure waste — the per-element TransformToAncestor + AdornerInfo update fires for stable transforms. Add a layer-level _layoutDirty flag, set on: - Add(adorner, zOrder) and SubscribeToElementLayout for each element - Remove(adorner) when any adorner is removed - SetAdornerZOrder, Update(), Update(element) - LayoutUpdated firing on any individually adorned element and cleared at the top of UpdateAdorner. Per-element LayoutUpdated subscriptions are tracked in a HashSet so subscribe/unsubscribe are balanced and the AdornerLayer/UIElement cycle is broken on removal. Caveat: RenderTransform changes don't fire LayoutUpdated. If the adorned content uses RenderTransform animation, the dirty bit will under-fire and adorners may lag a frame behind. Document; revisit if profile shows the regression. Expected reduction: combined with commit 1, takes the 3.20 GB inclusive UpdateAdorner attribution toward zero in steady-state UI; remaining cost only when something actually moves. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
UpdateElementAdorners' per-call `element.TransformToAncestor(parent)` was the dominant source of MatrixTransform (480 MB) + Matrix (427 MB) allocations in the take-open profile (~32% of total app alloc). Switch to the alloc-free `TryTransformToAncestorAsMatrix` (added in 96522a7) on the simple-affine path; fall back to the GeneralTransform overload only when the visual chain has Effects or 3D embedding. AdornerInfo gains a SimpleTransform (Matrix) + HasSimpleTransform discriminator alongside the existing Transform field. The hot UpdateElementAdorners comparison uses the Matrix == operator directly on the simple path. Downstream ArrangeOverride consumers use GetTransformForArrange(), which materialises a MatrixTransform from SimpleTransform only on the arrange pass (not the ~570/sec update path); on identity transforms it returns Transform.Identity to avoid even that allocation. Trade-off: AdornerInfo grows by sizeof(Matrix) + sizeof(bool) = 72 B per instance; acceptable given the per-adorner cardinality is low (typically 1-3 per element) and the hot-path savings are ~900 MB/run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ol the per-tick TimeIntervalCollection allocation in Clock.ComputeEvents and Clock.ComputeIntervalsWithHoldEnd via a [ThreadStatic] scratch struct on Clock + new in-place RebuildAsClosedOpenInterval / RebuildAsInfiniteClosedInterval mutating methods on TimeIntervalCollection that reuse the existing _nodeTime / _nodeIsPoint / _nodeIsInterval buffers. Eliminates 3 small array allocations (~96 B) per Clock per animation tick by replacing the CreateClosedOpenInterval / CreateInfiniteClosedInterval factory calls (which always allocated 3 fresh arrays via the private TimeIntervalCollection ctor's EnsureAllocatedCapacity) with mutate-in-place rebuild methods on a per-thread scratch field. Hot path (warm-lead candidate #3 from the post-fix profile, fresh 2026-05-10): - Clock.ComputeEvents fires every animation tick (~60 Hz × N animated clocks during playback). - Inside, lines 2597 / 2602 build an activePeriod TIC that is consumed only by two read-only intersection checks (parentIntervalCollection.Intersects(activePeriod) at line 2607 and parentIntervalCollection.IntersectsInverseOf(activePeriod) at line 2836 inside ComputeIntervalsWithParentIntersection). Neither call mutates activePeriod's underlying arrays — they pass it by value (struct copy with shared array refs) and only mutate the local copy's _current cursor via MoveFirst/MoveNext. - Clock.ComputeIntervalsWithHoldEnd at line 2800 builds the analogous fillPeriod TIC, used only for Intersects/IntersectsInverseOf. Mutually exclusive with the activePeriod path (the caller takes the Intersects-true OR Intersects-false branch but not both), so the same scratch slot serves both. Allocation accounting (pre-fix per call): EnsureAllocatedCapacity(_minimumCapacity=4) allocates: - new TimeSpan[4] ≈ 48 B (16 header + 32 payload) - new bool[4] ≈ 24 B (16 header + padded payload) - new bool[4] ≈ 24 B Total: ≈ 96 B per ComputeEvents / ComputeIntervalsWithHoldEnd call At ~60 Hz × 100 active clocks ≈ 6 000 calls/s × 96 B ≈ 576 KB/s steady-state churn. Profile attributes 49.7 MB combined alloc to Clock.ComputeEvents across the 3 scenarios. Files modified: - TimeIntervalCollection.cs: added two internal mutating methods, RebuildAsClosedOpenInterval(from, to) and RebuildAsInfiniteClosedInterval(from). Both mirror the existing private ctors line-for-line (including the from==to single-point degenerate case and the from>to swap path) but reuse the existing _nodeTime / _nodeIsPoint / _nodeIsInterval arrays via EnsureAllocatedCapacity (which is a no-op when arrays are already at _minimumCapacity=4). Explicitly resets _containsNullPoint, _invertCollection, _current to defaults, AND explicitly clears _nodeIsInterval[1] = false (the original ctor relied on the default-zero state of a fresh bool[] for that slot). - Clock.cs: added a [ThreadStatic] private static TimeIntervalCollection s_scratchActivePeriod field, and replaced the three TimeIntervalCollection.Create*Interval factory calls with the scratch-rebuild pattern: s_scratchActivePeriod.RebuildAs*Interval(...); local = s_scratchActivePeriod; Each call now COPIES the struct to a local (3 array refs + a few bools, ≈ 40 B stack copy) and passes the local through Intersects / IntersectsInverseOf as before — the underlying arrays remain owned by the [ThreadStatic] field across calls. Safety / aliasing analysis: - Clock.ComputeEvents runs on the dispatcher (UI) thread; [ThreadStatic] gives one scratch per thread, so no cross-thread races on the buffer. - Within a single ComputeEvents invocation, the scratch is built once (line 2597 or 2602), then read-only consumed by Intersects (line 2607) and possibly IntersectsInverseOf inside ComputeIntervalsWithParentIntersection (line 2836). Neither writes to the underlying arrays — they MoveFirst/MoveNext on local struct copies, mutating only the copies' _current cursors. - ComputeIntervalsWithParentIntersection eventually calls ComputeCurrentIntervals (virtual), which on ClockGroup calls TimeIntervalCollection.ProjectOntoPeriodicFunction — that operates on a different TIC (_currentIntervals on the ClockGroup) and never reads or writes our scratch. - ComputeEvents never recursively re-enters another Clock's ComputeEvents within its own call: the recursion lives at the TimeManager / ClockGroup.ComputeTreeState level (one Clock fully finishes ComputeLocalState → ComputeLocalStateHelper → ComputeEvents before the next sibling's ComputeLocalState runs). RaiseCurrentXInvalidated only marks state + adds to a deferred event queue; it does not synchronously dispatch user callbacks that might call back into the Clock tree mid-tick. - Stale slots beyond _count remain in the reused arrays but are never read (algorithms bound index access by _count via CurrentIsAtLastNode = (_current + 1 == _count)). - The activePeriod = TimeIntervalCollection.Empty branch at line 2593 (when expirationTime == _beginTime) is left untouched — Empty's default ctor never allocates (it returns a zero-init struct with _nodeTime == null, which Intersects short-circuits via IsEmptyOfRealPoints). Expected delta: - Tier C scenario-alloc on --scenario playback (animation-heavy): expected −1 to −5 MB WPF-attributed allocation per scenario (49.7 MB combined / 3 scenarios = ≈ 16 MB per scenario; not all of that is the activePeriod allocation — some is overhead in the constructor / call paths attributed up the stack — so a conservative bet is single-digit MB at the scenario granularity, which is well above the ≈ 50 KB Tier C floor). - Time delta: expected near-zero per-call (the rebuild method does the same field writes as the ctor; the only difference is skipping the array-allocation arithmetic on the GC fast path), but reduced GC pressure could yield small improvements at the scenario level.
Skip the per-LayoutUpdated walk entirely when no user-adorners are attached. The default AdornerLayer on every WPF window subscribes to LayoutUpdated unconditionally; without this guard, every pass calls UpdateAdorner → TransformToAncestor → InvalidateMeasure synchronously inside UpdateLayout, scheduling another render via NeedsRecalc → PostRender. This amplifies any forever-animation by ~17× — a perpetual busy spinner with no MC adorners attached produces ~570 renders/sec instead of ~32 (measured in MotionCatalyst take-open scenario, profile-output/take-open.nettrace 2026-05-09). Clears _layoutDirty before the early exit so a stale flag does not corrupt the dirty-bit lifecycle when the first adorner is later attached (oracle-panel correction, gemini 9/10 confidence). Combined with the dirty-bit guard from commit 5e7df88 and the TryTransformToAncestorAsMatrix fast path from 96522a7, eliminates the empty-AdornerLayer cascade entirely. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…oist the _isInCreateWindow field-read out of the HwndWrapper.WndProc hook iteration loop and out of the trailing CheckForCreateWindowFailure(result, true) call site, so that the (hookCount + 1) wasted CheckForCreateWindowFailure call frames per WndProc invocation on the dominant post-creation steady-state path (each frame would enter the helper's prologue, re-read the same _isInCreateWindow field, take the early-return branch, and unwind — pure overhead) are skipped entirely by a single hoisted bool local + two cheap branches. Filter: *HwndWin32* (eligible — 7 prior tier-B rows, last 3 all REJECT-UNCLEAR but only 1 KEEP total so the saturation rule does NOT cool it; 28 tier-B rows since the most recent run per cool-list.py; rank by alloc_pct_total ties with the dispatcher-pump frames at 0%, but bdn_filter coverage of HwndWrapper.WndProc + HwndSubclass.SubclassWndProc places it at the only direct-attack surface for the Win32 wrapper layer that doesn't overlap with the already-mined ExceptionWrapper / CultureContext / Dispatcher pump path). Cool list rebuild (Step 1 logged): *DispatcherOperationInvoke* (rows 70+77 REJECT-UNCLEAR, ROWS-SINCE=4 vs threshold=5; one more tier-B row needed before it becomes eligible). All other non-null bdn_filter entries eligible per cool-list.py output at iter start: *CultureContext* (last verdicts REJECT, KEEP, REJECT — not saturated, KEEP within last-3 window), *ExceptionWrapper* (KEEP, REJECT-UNCLEAR, REJECT — not saturated, KEEP within last-3 window), *DispatcherInvokeAction* (last 3 all REJECT-UNCLEAR, ROWS-SINCE=9 already past threshold), *GeometryParser* (off-profile per program.md, exhausted at v7 baseline), *HwndWin32* (eligible per above), *WindowLifecycle* (REJECT-UNCLEAR, REJECT — eligible but iter-081 demonstrated the +63 B/op alloc-noise brittleness on WindowShowDialog so deferring a same-day retry). Saturation check: only *GeometryParser* has 3+ KEEPs (9 KEEPs total, last 3 non-KEEP) — already cooled by the program.md "off-profile" rule, treat as cooled by saturation rule too. No other filter has 3+ KEEPs so saturation rule is inactive elsewhere. *HwndWin32* has 1 KEEP total — well under the 3+ threshold. Iter-number note: results.jsonl is at 78 rows but the commit-log sequence continues from iter=081 (b5fc07a, reverted by 374e373). The next commit-log slot is iter=082; the next harness run is expected to write row 79 of results.jsonl. Mechanism analysis: HwndWrapper._isInCreateWindow (private bool, defaulted false at line 366) is set to true on line 113 immediately before the CreateWindowEx P/Invoke inside the HwndWrapper ctor and is set back to false on line 130 inside the matching finally block (which runs whether CreateWindowEx succeeded or threw). After the ctor returns, the field is permanently false for the remaining lifetime of the HwndWrapper instance — no code path elsewhere in the file (or anywhere in the WindowsBase tree per grep) writes back to it. Every WndProc invocation that happens after construction completes therefore observes _isInCreateWindow == false. CheckForCreateWindowFailure(IntPtr result, bool handled) (line 282-298) is structured to return immediately when !_isInCreateWindow: private void CheckForCreateWindowFailure(IntPtr result, bool handled) { if (!_isInCreateWindow) return; // ... rest only runs during the in-ctor CreateWindowEx call ... } So on the steady-state path, every CheckForCreateWindowFailure call: 1. Pushes a stack frame (prologue: ~3-5 ns) 2. Reads `this._isInCreateWindow` from memory (the same field read on each call) 3. Takes the early-return branch 4. Unwinds the stack frame (epilogue) Two call sites in WndProc hit this pattern: - Inside the hook iteration loop, called once per hook (line 248 in current source) - Once unconditionally after the WM_NCDESTROY / s_msgGCMemory branches (line 276) For a single-hook HwndWrapper (the dominant case — most WPF chrome hwnds have 1 hook chaining into HwndSource): 2 wasted frames per WndProc. For a 4-hook HwndWrapper (composite windows with multiple subclass listeners): 5 wasted frames per WndProc. The JIT could in principle inline CheckForCreateWindowFailure since the body is small, but the throw / Debugger.Break / Debug.WriteLine in the cold path inflate its IL size past the inlining heuristic threshold, so it remains a real call frame in the disassembly. Fix: Read _isInCreateWindow once into a local at the top of WndProc, then gate both CheckForCreateWindowFailure call sites on the local. The semantics are unchanged: the helper still runs (now via the hoisted branch, with a slightly different stack frame composition) whenever _isInCreateWindow is true; the post-creation skip is now expressed as two cheap bool branches that fold cleanly with the JIT's branch predictor (always-false in steady state, always-true during the single in-ctor invocation). The hoisted local also documents the invariant that _isInCreateWindow does not change across the WndProc body — the field is only written from the ctor's main thread, but a defensive sequential read (vs reading via the field across the helper-call boundary) costs nothing and clarifies the optimization intent. Expected impact: Per-call savings on the steady-state path: - 1-hook bench (WndProc1Hook): 2 call frames * ~3-5 ns = ~6-10 ns - 4-hook bench (WndProc4Hooks): 5 call frames * ~3-5 ns = ~15-25 ns This is small relative to the bench's cross-thread SendMessage round-trip cost (~87 µs / op as documented in HwndWin32Benchmark.cs comment), so the Tier B harness is likely to report REJECT-UNCLEAR even though the structural improvement is real. The HwndWin32 cluster has a documented variance of thousands of ns on the time axis (per the last 7 tier-B rows in results.jsonl), making sub-100-ns wins statistically indistinguishable from noise on this surface. Filed under the program-prompt "swing big, ship small wins anyway" guidance. NegativeControlDefWndProc is unaffected (it bypasses the managed WndProc chain via DefWindowProc P/Invoke). Alloc delta: zero — no allocations added or removed; the local bool is a stack-resident JIT-optimized read. Goodhart-safety: the hoist preserves the trailing CheckForCreateWindowFailure(result, true) semantic (it was unconditionally called with handled=true; the gated version still invokes it with handled=true when _isInCreateWindow is true). The in-loop helper call still passes the per-hook handled value. Both the in-ctor diagnostic path (Debug.WriteLine / Debugger.Break / InvalidOperationException throw for non-zero result during CreateWindowEx) and the post-creation no-op path are preserved bit-for-bit. Files: src/Microsoft.DotNet.Wpf/src/Shared/MS/Win32/HwndWrapper.cs (WndProc, ~10 lines around lines 240-280).
…e per-Dispatcher cached `_defaultDispatcherSynchronizationContext` inside Dispatcher.PushFrameImpl instead of allocating a fresh `new DispatcherSynchronizationContext(this)` per frame push, killing one ~32 B heap allocation on every Dispatcher.PushFrame entry (Application.Run startup, every nested DispatcherFrame, Window.ShowDialog modal pump, all other frame pushes).
Target axis: alloc. Bench coverage: *WindowLifecycle*. The dominant per-iter
expected effect lives on the WindowShowDialog benchmark, which constructs a
fresh Window then calls ShowDialog() — that pushes a modal DispatcherFrame
via `Dispatcher.PushFrame(_dispatcherFrame)` (Window.cs:5581-5582), which
funnels through PushFrameImpl exactly once per iter. Each call previously
allocated a brand-new DispatcherSynchronizationContext on the heap; with
this change, the cached one created in the Dispatcher ctor (line 1743:
`_defaultDispatcherSynchronizationContext = new DispatcherSynchronizationContext(this)`)
is used directly. Same dispatcher reference, same DispatcherPriority.Normal,
same SetWaitNotificationRequired() state — semantically identical, zero
runtime difference modulo the avoided alloc.
Expected per-bench deltas:
- WindowShowDialog: alloc Δ -32 B/op (single PushFrameImpl per iter)
- WindowShowHideProxy: 0 (Show/Hide does not push a frame; STA's outer
PushFrameImpl was already paid once at thread startup, before BDN
measurement starts)
- NegativeControlDispatcherInvoke: 0 (cross-thread Invoke blocks on
DispatcherOperationEvent on the BDN thread, no PushFrame anywhere)
Time delta should be negligible (one less `newobj` instruction + ctor body
on a microsecond-scale modal-pump path). Alloc is the clean signal axis.
Safety / semantic-equivalence argument:
1. _defaultDispatcherSynchronizationContext is `new DispatcherSynchronizationContext(this)`
i.e. Normal-priority for this dispatcher — exact same constructor call
as the per-frame allocation.
2. DispatcherSynchronizationContext state is immutable post-ctor: only
_dispatcher and _priority fields plus SetWaitNotificationRequired()
called once. No per-frame mutation, no reset needed between uses.
3. Send/Post/Wait/CreateCopy on the DSC do not depend on reference
identity — they forward to _dispatcher / _priority. CreateCopy under
ReuseDispatcherSynchronizationContextInstance compat already returns
`this` (the same instance) so callers tolerating that path also
tolerate this cache reuse.
4. SetSynchronizationContext(newSync) + the matching finally
SetSynchronizationContext(oldSync) is balanced regardless of whether
newSync is fresh or cached. The outer PushFrame captures the
pre-pump SyncCtx (typically null or thread default) in oldSync,
installs cached DSC. Nested inner PushFrame would capture the cached
DSC in its own oldSync and install the cached DSC again (idempotent
write), then restore the cached DSC on inner exit (no-op), then the
outer exit restores the pre-pump SyncCtx. Identical observable
trajectory to the previous fresh-per-frame allocation.
5. _defaultDispatcherSynchronizationContext is set in the Dispatcher
ctor (line 1743) BEFORE any PushFrameImpl can fire (PushFrame
resolves Dispatcher.CurrentDispatcher first, so the dispatcher
instance is fully constructed). Single-threaded construction
ordering on the dispatcher thread; no race window.
This mirrors the same cached-DSC pattern already adopted in
LegacyInvokeImpl's Send-priority same-thread fast path (line 1289-1306,
which uses `_defaultDispatcherSynchronizationContext` /
`_sendDispatcherSynchronizationContext` instead of fresh allocations).
PushFrameImpl was the lone holdout in the dispatcher's Normal-priority
DSC-allocation surface.
… the most-recently-disposed HwndStyleManager instance into a per-Window pool slot (Window._freedStyleManager) and reuse it on the next StartManaging activation, killing one ~24-32 B heap allocation per Window.Show / Window.Hide cycle (and on every other StartManaging call site — CorrectStyleForBorderlessWindowCase, SizeToContent invalidation, ResizeMode change, etc.).
Hypothesis. SafeStyleSetter (Window.cs line 5612) is invoked by Window.ShowHelper after every successful ShowWindow on a created HWND (i.e. both the Show path and the Hide path execute it once each per Show+Hide cycle, as long as IsSourceWindowNull is false — which is the steady-state after the first Show creates the HWND). Each SafeStyleSetter `using (HwndStyleManager sm = HwndStyleManager.StartManaging(...))` enters StartManaging, which under the original implementation always allocated a fresh `new HwndStyleManager(w, Style, StyleEx)` whenever `w.Manager == null` — and Dispose immediately re-nulled Manager (refcount=0 path), guaranteeing that the next Show or Hide on the same Window paid another fresh allocation. The HwndStyleManager instance itself is small (3 fields: _window, _refCount, _fDirty) so each is ~24-32 B, but it allocates per ShowHelper invocation on steady-state, making it a clean structural-waste candidate.
Design. Add a private `HwndStyleManager _freedStyleManager` field on Window — a single-slot per-Window pool that holds the most recently disposed HwndStyleManager (= the one that just nulled itself out of Window.Manager). StartManaging is rewritten to:
1. Cache `w.Manager` into a local once at entry (one field load instead of three).
2. If non-null, increment its refcount and return (unchanged hot path for nested re-entrancy).
3. If null, prefer the pooled instance from `w._freedStyleManager` before falling back to `new HwndStyleManager(w)`.
4. Activate the (pooled or freshly allocated) manager by publishing it to `w.Manager` BEFORE writing `w._Style` / `w._StyleEx` (the original ordering — those property setters dereference `Manager.Dirty`, so Manager must be set first); then conditionally write the style fields under `!IsSourceWindowNull`, set Dirty=false (matches the original ctor's "freshly-read style cannot be dirty" invariant), and set _refCount=1.
The ctor is reduced to a minimal `_window = w` initializer so the instance is reusable. Dispose is unchanged except for the very last step on the refcount=0 / Manager==this branch: in addition to nulling `_window.Manager`, also park `this` into `_window._freedStyleManager` so the next StartManaging activation finds it.
Re-entrancy safety. The existing Dispose has a two-step re-entrancy guard for the case where Flush sends a window message whose handler triggers a nested StartManaging+Dispose (the comment block explicitly documents this scenario, originally fixed in the WindowStyle-animation NRE bug): (1) Flush takes a local copy of Manager up front, and (2) the outer Dispose only nulls Manager if `_window.Manager == this`. With the pool added, the same guard prevents a double-pool: if the nested Dispose has already nulled Manager and parked `this` into the pool, the outer Dispose sees `_window.Manager != this` and skips both the null-out and the pool-park. The reverse pathological case — pool-park races with concurrent StartManaging — cannot occur because Window is single-thread-affine (STA) and Dispose runs serially on that thread; the pool slot is a plain field, no locking needed. If a deeply nested chain pops `this` out of the pool, activates it, and re-disposes it before the outer Dispose resumes, the outer Dispose check `Manager == this` again returns false (last inner pool-park nulled it), so the outer no-ops. End-state in every nesting depth: `_freedStyleManager == this`, `Manager == null` — identical to the no-nesting case.
Lifecycle invariant. The pooled HwndStyleManager retains its `_window` reference across the borrow/return cycle (the field is set once in the ctor and never mutated), so the (instance, Window) binding is permanent. There is no cross-Window sharing — each Window has its own pool slot. The instance's _refCount and Dirty bit are fully (re-)initialized inside StartManaging on every activation, so no stale state survives across reuse.
Expected impact. Tier B `*WindowLifecycle*` benchmark: the WindowShowHideProxy body invokes SafeStyleSetter twice per Show+Hide (Show path + Hide path), so the per-iter allocation budget loses 2 × sizeof(HwndStyleManager) ≈ 48-64 B. The current baseline reports 31 B/op for the Show+Hide bench (under OperationsPerInvoke=50 scaling), the actual per-iter allocation is dominated by the Dispatcher.Invoke cross-thread plumbing (~1500+ B). The HwndStyleManager kill is a structural improvement that should at minimum register as a non-regression on alloc and a marginal-or-better time delta. Tier C scenario-alloc: every Window.Show / Window.Hide in startup + take-open + playback benefits — the impact is steady-state per-scenario (every window state transition saves one allocation), but the absolute byte count is small (a few hundred B per scenario), likely below the 50 KB Tier C threshold.
Expected verdict: KEEP on alloc-axis if the bench captures the HwndStyleManager kill above the 16 B threshold; REJECT-UNCLEAR if the larger Dispatcher.Invoke alloc-floor drowns out the 48-64 B savings. Either way the change is a clean structural removal of per-Window-state-transition allocation that compounds across scenarios.
Files modified:
src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Window.cs
- HwndStyleManager.StartManaging: rewrite to consult pool first
- HwndStyleManager ctor: reduce to minimal binding
- HwndStyleManager.Dispose: park instance into pool on refcount=0 path
- Window field block: add _freedStyleManager
…ache): isolate iter=088 piece #2 — replace the per-ShowDialog `new NativeMethods.EnumThreadWindowsCallback(ThreadWindowsCallback)` delegate allocation with a single AppDomain-wide cached static delegate (Window.s_threadWindowsCallback) routed through a [ThreadStatic] target slot (s_tlsEnumThreadWindowsTarget) that ShowDialog sets immediately before EnumThreadWindows and restores in a finally block immediately after. Hypothesis. Iter=088 (commit 1a389ce, reverted to 8b22668) attempted three coordinated allocation kills on the Window.ShowDialog modal path: (1) [ThreadStatic] List<IntPtr> pool for _threadWindowHandles, (2) static cached EnumThreadWindowsCallback delegate, (3) [ThreadStatic] DispatcherFrame pool with ResetForPushFrame helper that bypassed the public Continue-setter's BeginInvoke side-effect. The combined package regressed WindowShowDialog alloc by +61 B/op vs the iter=087 baseline (30954 -> 31015 B/op). We do not know which of the three pieces caused the regression — could be a single piece, could be cross-interaction (e.g. the DispatcherFrame pool's bypassed BeginInvoke side-effect changing how nested pump operations were enqueued). The fastest way to localize is to re-attempt each piece in isolation and observe which KEEPs cleanly. This iter attempts ONLY piece #2 (the delegate cache). It is the cleanest of the three: * The semantics of EnumThreadWindows are well-defined: the OS dispatches the callback synchronously inline for every visible thread window and returns after the last invocation. There is no nested-thread / async surface. * The TLS slot is live only for the duration of a single synchronous OS call. Nested ShowDialog is handled by the save-and-restore pattern (`prevEnumTarget = s_tlsEnumThreadWindowsTarget; ... s_tlsEnumThreadWindowsTarget = prevEnumTarget` in a finally) — a nested ShowDialog overwrites the slot, does its own EnumThreadWindows, restores the outer's value on unwind. * The static delegate is allocated exactly once at Window's type-init (`private static readonly EnumThreadWindowsCallback s_threadWindowsCallback = new EnumThreadWindowsCallback(ThreadWindowsCallbackStatic)`), shared across every Window instance and every thread. The per-call allocation is replaced by two TLS field-writes. * No public API is bypassed (in contrast to iter=088 piece #3 which bypassed the public DispatcherFrame.Continue setter's BeginInvoke side-effect). The instance ThreadWindowsCallback method is preserved unchanged; only the dispatcher (static -> instance) is rerouted via the TLS slot. Design. * Add a new private static method ThreadWindowsCallbackStatic(IntPtr hWnd, IntPtr lparam) that reads the TLS target Window from s_tlsEnumThreadWindowsTarget, asserts it is non-null (set by ShowDialog's enclosing save-and-restore), and delegates to its instance method ThreadWindowsCallback. * Add private static readonly s_threadWindowsCallback initialized once at type-init to a delegate over ThreadWindowsCallbackStatic. * Add private [ThreadStatic] static Window s_tlsEnumThreadWindowsTarget. Lifetime: live only during ShowDialog's EnumThreadWindows call (set immediately before, restored immediately after via finally). * Rewrite the ShowDialog call site (line ~344-352): save `Window prevEnumTarget = s_tlsEnumThreadWindowsTarget`, set the slot to `this`, call EnumThreadWindows with the cached s_threadWindowsCallback, restore the slot in finally. Correctness invariants preserved. * The instance ThreadWindowsCallback method is unchanged — same Debug.Assert, same IsWindowVisible+IsWindowEnabled filter, same Add semantics, same return true. * The exception path in ShowDialog (catch block at line 391-447) is unchanged — _threadWindowHandles handling is independent of the delegate-cache change. * Nested ShowDialog: save-and-restore via prevEnumTarget restores the outer Window's slot on inner unwind. Even if the outer Window happens to be GC'd between nested unwind and outer's own callback (impossible — the outer is a live local in the outer ShowDialog stack frame), the slot would be set to null, the static callback's Debug.Assert would fire in DEBUG, and in release the null-deref would throw — the same fail-fast behavior as if a hypothetical caller invoked EnumThreadWindows without setting the slot. * Exception during EnumThreadWindows: the finally block restores the slot. EnumThreadWindows is not documented to throw on common paths; if the OS or marshalling layer were to throw, slot restoration is correct. Expected verdict. * WindowShowDialog alloc-axis: -24 to -56 B/op (kill one EnumThreadWindowsCallback instance per ShowDialog call). The exact size depends on whether the delegate is a single-target instance delegate (32-48 B) or includes additional marshalling overhead for the P/Invoke (potentially adding a thunk allocation per call inside the runtime, in which case the savings shrink). The 16 B/op microbench floor is the threshold for a KEEP. * WindowShowHideProxy + NegativeControlDispatcherInvoke: no change (the change touches only the EnumThreadWindows call inside ShowDialog). * Time-axis: tiny win (one delegate allocation skipped per ShowDialog) but well below the 5 ns/op floor on the per-iter ShowDialog cost (~30 us baseline). Files modified. src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Window.cs - ShowDialog (~line 344): replace `new EnumThreadWindowsCallback(ThreadWindowsCallback)` with TLS save/set + cached delegate + finally restore - Add ThreadWindowsCallbackStatic static method (~line 3611) that routes via the TLS slot - Add static readonly s_threadWindowsCallback and [ThreadStatic] s_tlsEnumThreadWindowsTarget field declarations (~line 7265)
…l): isolate iter=088 piece #1 — replace the per-ShowDialog `new List<IntPtr>()` allocation for `_threadWindowHandles` with a [ThreadStatic] single-slot pool (Window.s_freedThreadWindowHandles) so the grown IntPtr[] capacity survives across ShowDialog calls on the same UI thread; EnableThreadWindows(true) clears the list contents and returns it to the slot in place of just nulling the field; the next ShowDialog on the same thread pops the slot and pays zero allocation for both the List header and the backing array. Hypothesis. The reverted iter=088 bundled three coordinated allocation kills on the Window.ShowDialog modal path: (1) List<IntPtr> _threadWindowHandles pool, (2) EnumThreadWindowsCallback delegate cache, (3) DispatcherFrame pool. The bundle showed alloc Δ +61 B/op on WindowShowDialog. iter=089 extracted piece #2 alone (delegate cache) and KEEPed at -62 B/op. The remaining +123 B/op net regression therefore lives in pieces #1 and #3 combined. This iter extracts piece #1 in isolation. The change is the simplest, lowest-risk sub-piece: a pure storage pool with zero semantic change to the callback path, to EnumThreadWindows itself, or to the modal-pump frame lifecycle. There is no internal-helper method introduced (unlike piece #3, which needed DispatcherFrame.ResetForPushFrame to bypass the public Continue setter's BeginInvoke side-effect), no [ThreadStatic] cross-method coordination (unlike piece #2's s_tlsEnumThreadWindowsTarget which is read by a static callback during EnumThreadWindows), and no observable change to the existing `Debug.Assert(_threadWindowHandles == null)` entry-side invariant or the existing nullout-on-EnableThreadWindows(true) field-lifecycle contract. Design. • [ThreadStatic] s_freedThreadWindowHandles: holds the most recently emptied List<IntPtr> for the current UI thread. ShowDialog pops the slot (or allocates fresh on first call); EnableThreadWindows(true) clears the list and returns it to the slot. The list's IntPtr[] backing capacity is preserved across the borrow/return cycle, so steady-state ShowDialog pays zero allocation for the list header AND zero allocation for the IntPtr[] backing array growth steps (the 0→4→8→16 stages each allocate fresh sub-arrays under the current `new List<IntPtr>()` regime — preserved capacity skips all of these). • Nested ShowDialog is safe under single-slot last-writer-wins semantics: the outer call has popped the slot or fresh-allocated; the nested call (running on the same STA thread between outer's pop and outer's park) hits an empty slot and fresh-allocates; the nested call parks its own instance at its EnableThreadWindows(true), evicting any concurrent state — benign because each call's _threadWindowHandles is a per-Window-instance field and is never shared across ShowDialog activations; the worst case is one wasted-reuse on the next call after the outer returns, then steady-state pooling resumes. • The pool slot is single-element (no list of pooled instances) — minimal additional state, matches the iter=087 HwndStyleManager._freedStyleManager pattern (single-element pool, last-writer-wins eviction, GC reclaims the loser). Correctness invariants preserved. • The existing entry-side assertion `Debug.Assert(_threadWindowHandles == null)` at line 336 still holds — EnableThreadWindows(true) continues to null _threadWindowHandles after the pool-park step, in the same order as before (null the field, then optionally park the captured local). • The static EnumThreadWindowsCallback path (s_threadWindowsCallback → ThreadWindowsCallbackStatic → instance ThreadWindowsCallback) is untouched. The static callback reads `this._threadWindowHandles` exactly as before (via the s_tlsEnumThreadWindowsTarget slot from iter=089) — the pool only changes WHERE _threadWindowHandles was originally sourced from, not how it is subsequently consumed. • The exception path in ShowDialog (catch block at line ~411-467) calls EnableThreadWindows(true) on `_threadWindowHandles != null` to re-enable disabled windows. With pooling, the exception-path EnableThreadWindows(true) additionally parks the list. This is correct: the list contents have been cleared (the EnableWindow(true) iteration has completed by the time EnableThreadWindows reaches the state=true branch), so the parked list is empty and ready for the next ShowDialog. The exception ultimately rethrows; the parked list remains in the slot for the next ShowDialog regardless of whether the exception propagated out of ShowDialog or was caught by a higher frame. • List<IntPtr>.Clear() is a single _size=0 store: IntPtr is a value type (no GC-tracked references inside), so the List's internal Array.Clear over the still-tracked portion is a no-op for ref-type zeroing purposes; the .NET 8+ List<T>.Clear specialization for value-type T elides the Array.Clear entirely. No allocation occurs in Clear(). • The pooled list survives ONLY across ShowDialog calls — it has no exposure to user code, no leak path, and no lifetime extension beyond the AppDomain (the [ThreadStatic] slot dies with the thread). Why piece #1 in isolation and not piece #3. • Piece #1 is the largest expected absolute saving: a fresh `new List<IntPtr>()` allocates a 24 B List<IntPtr> header. The first Add grows capacity to 4, allocating an IntPtr[4] (48 B); the next Add at capacity boundary grows to 8 (80 B); then to 16 (144 B) on a typical desktop with N≈10 visible thread windows. Each grow allocates a fresh IntPtr[] and discards the prior one. Total per-call alloc: 24 + 48 + 80 + 144 = 296 B (List header + sum of grow-step allocations). After priming, the pool retains capacity 16 — every subsequent ShowDialog skips the grow steps and pays zero. Expected steady-state savings: -200 B/op to -296 B/op, well above the 16 B/op alloc floor. • Piece #3 (DispatcherFrame pool) has a smaller expected saving (24-32 B per DispatcherFrame) and carries a subtle correctness concern (the ResetForPushFrame helper bypasses the Continue setter's BeginInvoke side-effect — correct in principle but adds coupling to two files). Piece #3 is also the more plausible source of iter=088's +123 B/op regression: if the Continue=false BeginInvoke fires while the pump is between exit and park, the queued no-op DispatcherOperation may live longer than intended, holding the DispatcherFrame past the slot-park point and effectively wasting the slot. • Splitting the bundle isolates the experiment: if piece #1 KEEPs (this iter), iter=088's regression is fully attributed to piece #3. If piece #1 REJECTs, it was the bundle's problem and piece #3 may also be re-examinable on its own. Expected impact. Tier B `*WindowLifecycle*` benchmark: • WindowShowDialog (1 ShowDialog per benchmark op, fresh Window per iter, shared STA thread across all iters → pool primes after iter 1): expected alloc Δ -200 B/op to -296 B/op. Current baseline 30892 B/op (post iter=089 KEEP at -62 B/op). The pool slot is set on the first measured iter's EnableThreadWindows(true) call; iters 2..N see the steady-state savings. With 3 warmups + 10 measured iters, the pool primes during warmup, so all 10 measured iters see the full savings. • WindowShowHideProxy (50 Show+Hide ops per measurement): NOT touched — Show/Hide do not invoke the ShowDialog code path. Expected alloc Δ: 0 B/op (within noise). • NegativeControlDispatcherInvoke: NOT touched. Expected Δ: 0 / noise. • Time axis: zero expected change. The pop-or-fresh-allocate branch on the hot path is a single TLS read + null-check + assignment — the same level of work as `new List<IntPtr>()` plus its embedded zero-init. Time delta should be sub-floor noise. Files modified: src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Window.cs - field block (~line 7279): add [ThreadStatic] s_freedThreadWindowHandles single-slot pool field - ShowDialog body (~line 344): replace `new List<IntPtr>()` with pool-pop / fresh-allocate fallback - EnableThreadWindows (state=true branch, ~line 3672): clear and park to the pool slot in place of just nulling _threadWindowHandles Expected verdict: KEEP on WindowShowDialog alloc-axis at -200 B/op or better (well above the 16 B/op floor); REJECT-UNCLEAR on the two other benchmarks (no signal). If verdict comes back REJECT, the most likely explanation is the list pool measurably interferes with something I have not modeled — in which case iter=088's +123 B/op regression is split between pieces #1 and #3 and the safer next move is to leave the WindowLifecycle target cool for a few iters and pick a different hot path.
… eliminate the per-DispatcherOperation `new DispatcherSynchronizationContext(_dispatcher, _priority)` heap allocation in `DispatcherOperation.InvokeImpl` AND the matching per-`Dispatcher.Invoke` allocations in the public `Invoke(Action,…)` / `Invoke<TResult>(Func<TResult>,…)` Send same-thread fast paths by routing them through a per-Dispatcher per-priority DSC cache, extending the iter=086 `_defaultDispatcherSynchronizationContext` (Normal) / `_sendDispatcherSynchronizationContext` (Send) singleton pattern to the variable-priority queued-op path.
Two distinct sites pay per-call DSC allocs today under the .NET Core defaults (reuseInstance=false, flowPriority=true — the only configuration in scope here):
1. `Dispatcher.Invoke(Action callback, DispatcherPriority priority, CancellationToken, TimeSpan)` line 583-597 — same-thread Send-priority synchronous-invoke fast path. priority is statically Send inside the guard. Allocates `new DispatcherSynchronizationContext(this, priority)` (= `new DSC(this, Send)`) on every Invoke. Mirrored in `Invoke<TResult>(Func<TResult>, …)` line 725-740 (Func/result-returning overload, identical Send fast path).
2. `DispatcherOperation.InvokeImpl` line 495-510 — the queued-op InvokeImpl run by every `op.Invoke()` dequeued out of `Dispatcher.ProcessQueue`. `_priority` is whatever the caller queued the op at (Normal/Send/Render/Input/Background/…). Allocates `new DispatcherSynchronizationContext(_dispatcher, _priority)` on every dispatcher pump iteration.
Both are inclusive-stack frames at the top of the `profile.json` *Dispatcher* hot path (alloc_pct_total=4.48% each). The bare `*Dispatcher*` BDN filter (matching both `DispatcherInvokeActionBenchmark` and `DispatcherOperationInvokeBenchmark`) has not been mined recently — the sub-filters `*DispatcherInvokeAction*` and `*DispatcherOperationInvoke*` saturated to REJECT-UNCLEAR on CPU-axis micro-opts (delegate caching, lock elimination, etc.) but the alloc-axis attack on the DSC heap object has not been tried.
For site 1 (public Invoke fast paths), priority is statically Send, so the cached `_sendDispatcherSynchronizationContext` field constructed in the ctor (iter=086) is directly substitutable. The Action and Func overloads now mirror the existing `LegacyInvokeImpl` pattern: read the ctor-captured `_reuseDispatcherSyncCtxInstance` + `_flowDispatcherSyncCtxPriority` bools, branch to the matching cached singleton. Side benefit: skips two `BaseCompatibilityPreferences.Get*()` static method calls per Send-Invoke (each does Seal+volatile-read).
For site 2 (variable-priority InvokeImpl), `_priority` is dynamic — one cached singleton is not enough. Add a new per-Dispatcher array `_priorityDispatcherSyncContexts[11]` indexed by `(int)DispatcherPriority` (valid range [Inactive=0..Send=10]; ValidatePriority gates the enum upstream). The array is allocated in the Dispatcher ctor at size 11, with the Normal slot pre-populated with `_defaultDispatcherSynchronizationContext` and the Send slot pre-populated with `_sendDispatcherSynchronizationContext` — these are the two dominant priorities for queued ops and would otherwise need a lazy-fill round-trip on the very first dispatch. Other priorities (Background, Input, Render, DataBind, Loaded, ApplicationIdle, ContextIdle, SystemIdle, Inactive) fill their slot on first touch via `GetOrCreatePrioritySyncContext`, which the JIT can [AggressiveInlining] thanks to its three-instruction fast path (array load → slot read → null-check); the rare lazy-fill goes through `GetOrCreatePrioritySyncContextSlow` (NoInlining) so InvokeImpl's epilogue stays tight.
The rare opt-out config (reuseInstance=false && flow=false) is preserved verbatim — both call sites continue to allocate `new DispatcherSynchronizationContext(_dispatcher, Normal)` per call, matching the explicit comment in LegacyInvokeImpl: "Preserve the original per-call Normal-priority alloc so callers that key off reference identity in this config continue to see a unique instance."
Safety story (per-thread reference-inequality semantics, same as iter=086): the cache is keyed on Dispatcher instance, and each Dispatcher is bound to one STA thread (the dispatcher thread). All cache reads and lazy fills happen on the dispatcher thread itself (InvokeImpl runs there; the Invoke Send fast path is guarded by CheckAccess()). Cross-thread ExecutionContext flow continues to route through `DispatcherSynchronizationContext.CreateCopy()`, which is unchanged and still allocates a fresh `new DSC(_dispatcher, _priority)` per copy — so when EC is restored on a non-dispatcher thread, that thread's Current becomes a *fresh* DSC, not the cached one. TPL's task-continuation inlining check (`if (Current == captured) inline`) sees fresh != cached → no incorrect inlining (the WPF 4.5 fix's invariant). On the dispatcher thread itself, the check correctly returns true for inlining, which is the desired behavior (we are in fact on the dispatcher).
Expected impact:
- `*DispatcherInvokeAction*` benchmarks (InvokeAction, InvokeAction4Arg): ~32 B/op alloc reduction (kills the per-call `new DSC(this, Send)`). priority=Send in both → hits `_sendDispatcherSynchronizationContext`.
- `*DispatcherOperationInvoke*` benchmark (DispatcherOperationInvoke): ~32 B/op alloc reduction. The benchmark constructs a fresh DispatcherOperation at `Priority.Normal` and invokes it via reflection; priority=Normal → hits the pre-filled `_priorityDispatcherSyncContexts[(int)Normal]` slot which is the same `_defaultDispatcherSynchronizationContext` singleton.
- Negative controls (`DispatcherInvokeAction.NegativeControlDirectCall`, `DispatcherOperationInvoke.NegativeControlDirectCall`): unaffected — neither goes through Dispatcher.Invoke or InvokeImpl.
Both above-threshold for the 16 B/op alloc floor (CV ≈ 0 on the BDN Allocated column). CPU axis is incidental: Invoke fast paths save two static method-call frames (BaseCompatibilityPreferences.Get*() static reads collapse to two cached bool field reads); InvokeImpl saves the DSC ctor body (one `_dispatcher` field write + one `_priority` field write + `SetWaitNotificationRequired` p/invoke). These are 5-10 ns/op micro-savings — possibly registering on the time axis, possibly sub-noise; the alloc-axis win is the primary objective.
Files modified:
- `src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs`:
* Added field `_priorityDispatcherSyncContexts` (DispatcherSynchronizationContext[]).
* Allocated the array in the ctor (size 11) and pre-populated Normal + Send slots.
* Added internal method `GetOrCreatePrioritySyncContext(DispatcherPriority)` (AggressiveInlining fast path; NoInlining slow path).
* Rewrote the Send fast path in `Invoke(Action,…)` and `Invoke<TResult>(Func<TResult>,…)` to use the cached singletons + cached compat bools, mirroring the existing LegacyInvokeImpl pattern.
- `src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/DispatcherOperation.cs`:
* Rewrote `InvokeImpl`'s DSC-selection block (the `if (FlowPriority) { … }` branch) to call `_dispatcher.GetOrCreatePrioritySyncContext(_priority)` instead of allocating a fresh DSC per op.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…yItem<T> nodes in PriorityQueue (WindowsBase) so steady-state Dispatcher.BeginInvoke / InvokeAsync / non-Send-priority Invoke no longer allocates a fresh ~64 B `new PriorityItem<DispatcherOperation>(data)` per queued op — extends the iter-093 per-(Dispatcher, priority) DispatcherSynchronizationContext-cache KEEP to the *next* per-op allocation in the same queued-dispatch critical path. Adds a sibling _cacheReusableItems Stack<PriorityItem<T>> (cap=10, mirroring the existing _cacheReusableChains pool) fed by RemoveItem (which clears _data via ClearForPool + pushes the now fully-nulled node) and consumed by Enqueue (pops + Reset rebinds _data, falls back to new allocation only when the pool is empty). Second attempt — first attempt (commit 5daadd7, auto-reverted as BENCH-FAIL) was a textbook bug: PriorityQueue.Dequeue read `item.Data` AFTER calling RemoveItem(item), but the new RemoveItem clears `_data` via ClearForPool before pushing the node to the pool. Dequeue therefore returned default(T) instead of the operation, ProcessQueue's `op = _queue.Dequeue()` got null, and the immediately-following `op._item = null` stamp NRE'd. Fix: capture `T data = item.Data` before RemoveItem in Dequeue and return that. This was also called out (and fixed correctly) in the prior iter-077 attempt of this same mechanism — I missed re-applying it. Peek does NOT have this issue (it reads item.Data without calling RemoveItem). No other caller reads item.Data after RemoveItem. The previous attempt at this pool (iter=077, commit fddae2e) was REJECT-UNCLEAR on Tier C take-open. That attempt did not run Tier B because at the time `*WindowLifecycle*` was off the path allowlist, and `*DispatcherInvokeAction*` / `*DispatcherOperationInvoke*` Tier B benchmarks do not exercise the queued path. After iter-088's PF DWF-cycle fix added PresentationFramework to the allowlist, the `*Dispatcher*` filter now covers `WindowLifecycleBenchmark.NegativeControlDispatcherInvoke` — which calls `Dispatcher.Invoke(work, DispatcherPriority.Normal)` cross-thread from BDN's worker thread to the STA Dispatcher, taking the slow path through DispatcherOperation construction + InvokeAsyncImpl + _queue.Enqueue + STA-thread ProcessQueue + Dequeue. Iter-093 measured this benchmark at 784 → 744 B/op alloc (Δ -40, KEEP) by killing the per-op DSC alloc on the QUEUED side of InvokeImpl. PriorityItem<DispatcherOperation> is approximately the next-largest per-op alloc on the same path: object header + 6 reference fields (_data, _sequentialPrev, _sequentialNext, _chain, _priorityPrev, _priorityNext) ≈ 64 B per op. Steady-state queue depth in NegativeControlDispatcherInvoke is 1 (one op posted per iter, dequeued before the next is posted), so the pool warms in one iter and every subsequent iter is a Pop-Reset / RemoveItem-Push pair under the already-held _instanceLock, with zero allocation. Expected alloc Δ on `*Dispatcher*` filter: NegativeControlDispatcherInvoke -64 B/op (744 → ~680). The other 5 benchmarks under the filter (DispatcherInvokeActionBenchmark.{InvokeAction, InvokeAction4Arg, NegativeControlDirectCall}, DispatcherOperationInvokeBenchmark.{DispatcherOperationInvoke, NegativeControlDirectCall}) all bypass _queue.Enqueue entirely (Send-fast-path same-thread or reflection-direct-invoke) so they should report Δ +0 B/op + Δ ~0 ns/op (REJECT-UNCLEAR each, the filter passes overall on the WindowLifecycle alloc win). Time Δ on NegativeControlDispatcherInvoke expected ~0 — replacing a `new PriorityItem<T>(data)` with a Stack.Pop + Reset under an already-held lock is a wash on cycle count. Pool-reuse safety: the only invariant required is that a pool-popped-and-reassigned PriorityItem cannot be observed via a stale back-pointer in another DispatcherOperation. The Dispatcher holds operation._item, which points at the PriorityItem assigned during InvokeAsyncImpl's Enqueue and is read back in four places — ProcessQueue's Dequeue path, SetPriority, Abort plus InvokeAsyncImpl's failed-enqueue branch. After this commit every site that hands a PriorityItem to RemoveItem (or that receives one back from Dequeue) immediately clears operation._item = null while still holding _instanceLock, so a later same-thread / cross-thread Abort() / SetPriority() that takes _instanceLock cannot reach a pool-reissued node now bound to a different op. SetPriority and Abort grow a defensive `operation._item != null` guard so the post-dequeue cleared back-pointer is treated as "not in queue" (which it isn't — the op has been dequeued or already aborted). Pre-pool semantics are preserved bit-for-bit: a same-thread Abort() on an already-dequeued op was a no-op (operation._item.IsQueued returned false because RemoveItem cleared item._chain), and the post-pool path is also a no-op (operation._item is null short-circuits the `&&`). ClearForPool nulls the _data back-reference before pushing the node, so a long-lived pooled node never keeps a completed DispatcherOperation (and its captured Action/delegate target graph) alive across dispatcher cycles. The post-RemoveItem invariant (the 4 linked-list pointers + _chain all null) means InsertItemInSequentialChain / InsertItemInPriorityChain's `item.SequentialPrev == null && item.SequentialNext == null` and `item.Chain == null && item.PriorityPrev == null && item.PriorityNext == null` Debug.Asserts continue to hold after a Reset(data) just like they held after a fresh `new PriorityItem<T>(data)`. Files modified: - src/Microsoft.DotNet.Wpf/src/WindowsBase/MS/Internal/PriorityItem.cs — add internal Reset(T data) (rebinds _data on pool-pop) and internal ClearForPool() (drops _data back-reference on pool-push). PriorityItem is internal; methods are internal. - src/Microsoft.DotNet.Wpf/src/WindowsBase/MS/Internal/PriorityQueue.cs — add _cacheReusableItems Stack<PriorityItem<T>> field + ItemPoolCapacity=10 const, initialized alongside _cacheReusableChains. Enqueue pops + Resets when non-empty, allocates when empty. RemoveItem clears + pushes when below cap. **Dequeue captures `T data = item.Data` BEFORE RemoveItem so the pool-push-clears-_data step doesn't leak through as a null return** (this is the fix that distinguishes this commit from the auto-reverted 5daadd7). - src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs — four call-site changes, all inside _instanceLock: (1) InvokeAsyncImpl's failed-enqueue branch clears operation._item = null after _queue.RemoveItem; (2) SetPriority adds the `operation._item != null` defensive guard; (3) Abort adds the same defensive guard AND clears operation._item = null after _queue.RemoveItem; (4) ProcessQueue clears op._item = null right after _queue.Dequeue() returns the op. Tier choice: Tier B `*Dispatcher*` filter — the right harness for a per-op micro-allocation kill, with NegativeControlDispatcherInvoke as the alloc-sensitive proof point (the same benchmark that registered the iter-093 +40 B DSC win).
…ross-thread DispatcherOperationEvent (wrapper + ManualResetEvent + 2 EventHandler delegates) via a [ThreadStatic] single-slot pool, so every cross-thread Dispatcher.Invoke(...) wait — i.e. every external-thread caller blocking on a queued op — stops allocating its per-call wait infrastructure quartet.
Hypothesis: profile.json's iter=094 ranks `DispatcherOperation+DispatcherOperationEvent.WaitOne()` at 1.9% cpu_pct on take-open/playback (same stack frame as `DispatcherOperation.Wait()` and `Dispatcher.InvokeImpl(...)`). The bench WindowLifecycleBenchmark.NegativeControlDispatcherInvoke — covered by `*Dispatcher*` and the dominant alloc-axis bench for that filter — does `Dispatcher.Invoke(Action, DispatcherPriority.Normal)` from the BDN host thread to an STA dispatcher thread; CheckAccess() is false so it takes the queued path, then InvokeImpl→operation.Wait()→DispatcherOperationEvent.WaitOne(). That bench currently reads 680 B/op after iters 093 (DSC per-priority cache, 784→744) and 094 (PriorityItem<T> pool, 744→680). Each of those two prior KEEPs landed by killing exactly the kind of per-call alloc this iter targets next on the same hot wait path.
Per-wait allocations eliminated in steady-state on the caller thread:
* `new DispatcherOperationEvent(...)` — ~40 B wrapper
* `new ManualResetEvent(false)` — ~32 B object + kernel handle (was Closed() per wait)
* `new EventHandler(OnCompletedOrAborted)` × 2 — ~32 B each, 64 B total
(subscribe; the `-=` cleanup allocated two MORE
EventHandler instances which delegate-equality
matched against the originals via (target,method))
Total saved per cross-thread Wait: ~128 B/op steady-state, plus 2 more EventHandler allocs from the cleanup `-=` arguments that the original code created and immediately discarded.
Design:
1. Add `[ThreadStatic] private static DispatcherOperationEvent s_pooled` slot. Per-thread isolation is sufficient because Wait() is synchronous on the caller thread: the wrapper is exclusively owned from Acquire through the WaitOne tail. Nested cross-thread waits on the same thread (rare) gracefully fall back to the ctor allocation path; only the innermost wait gets pooled on the way out, which is exactly the behavior we want.
2. Add static `Acquire(op, timeout)` factory. Pops from `s_pooled` if non-null and calls `Initialize(op, timeout)`; otherwise calls the (now-private) ctor.
3. Split the original ctor into a cold-start ctor + `Initialize(op, timeout)`. Cold ctor allocates `_event = new ManualResetEvent(false)` AND `_completedOrAbortedHandler = new EventHandler(OnCompletedOrAborted)` once per pooled instance — both as readonly fields. The cached handler is bound to this wrapper instance for the lifetime of the pooled object and gets reused for both Aborted/Completed subscribe AND the symmetric `-=` cleanup (which now uses reference identity instead of relying on delegate equality with newly-allocated EventHandlers).
4. Replace the per-WaitOne `_event.Close()` with `_event.Reset()` + return-to-pool. The original Close() was motivated by "high-activity component — could run out of events"; with [ThreadStatic] pooling we hold AT MOST ONE kernel event per thread that ever cross-waits a Dispatcher, which is the opposite end of the spectrum — strictly bounded, far below the original failure mode.
Concurrency analysis:
- The dispatcher's Completed/Aborted raise pattern captures `handler = _completed` INSIDE DispatcherLock and then calls `handler(this, args)` synchronously OUTSIDE the lock (DispatcherOperation.Invoke). OnCompletedOrAborted acquires DispatcherLock, sets _event, releases. The synchronous handler invocation by the dispatcher does NOT return until OnCompletedOrAborted has fully run (returned) — i.e. by the time _event becomes signaled and the WaitOne wakes on the caller thread, OCA has already returned, so no deferred OCA invocation is in flight when we Reset + pool the wrapper.
- There is no race against a future re-use of the pooled wrapper: the only path that could spuriously call OCA against the wrapper after pool-return would require the dispatcher to have captured the OLD operation's handler list pre-cleanup but invoked it post-cleanup. Since the dispatcher's `handler(this, args)` call is synchronous and OCA returns before the lock-protected Set finishes, that capture-vs-invoke window does not extend past the lock release that allows our cleanup to acquire the lock. After cleanup removes the handler from the operation's invocation list under the same DispatcherLock, no further raise of the OLD operation can target the wrapper.
- [ThreadStatic] guarantees no cross-thread race on the pool slot itself.
- Single-Initialize-per-Acquire lifecycle is preserved: each pooled instance sees Initialize → handlers subscribed → wait → handlers unsubscribed → pool, with no overlapping users on the same thread.
Files: src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/DispatcherOperation.cs (one file, atomic).
Expected alloc Δ on WindowLifecycleBenchmark.NegativeControlDispatcherInvoke: ~-128 B/op (680 → ~552). Smaller effect possible on DispatcherInvokeActionBenchmark.* (those are Send-priority same-thread fast path and don't go through DispatcherOperationEvent at all → no expected change, no expected regression).
NOTE: profile.json was refreshed mid-iter (computed_at 2026-05-11T09:21:00Z). `DispatcherOperation+DispatcherOperationEvent.WaitOne()` remains 1.9% cpu in the new profile.
…pping): skip the per-op `new DispatcherOperationTaskMapping(this)` allocation (~24 B/op) on the synchronous Dispatcher.Invoke(Action,...) slow path — the only path where the DispatcherOperation and its Task are guaranteed-unobservable to user code because Invoke returns void and the op goes out of scope at the call site. The Mapping wrapper exists solely as the Task.AsyncState discriminator for the public TaskExtensions API (IsDispatcherOperationTask / DispatcherOperationWait in System.Windows.Presentation/TaskExtensions.cs). Every DispatcherOperation construction pays this ~24 B unconditionally — but on the sync void-Invoke slow path the caller is `Dispatcher.Invoke(Action, ...)` returning void, which constructs the op locally, waits on it via op.Wait (Task.GetAwaiter().GetResult() / DispatcherOperationEvent — both AsyncState-agnostic), and lets the op + Task go out of scope when Invoke returns. The user never gets a handle to either, so Task.AsyncState is unobservable on that path, and the Mapping is pure waste. Wire-up: * DispatcherOperationTaskSource gains a new abstract method `InitializeWithoutMapping(DispatcherOperation)` overridden in the generic concrete `DispatcherOperationTaskSource<TResult>` to construct the inner TaskCompletionSource via its DEFAULT ctor (`new TaskCompletionSource<TResult>()`) instead of the state-carrying ctor (`new TaskCompletionSource<TResult>(new DispatcherOperationTaskMapping(operation))`). The resulting Task has AsyncState=null. * DispatcherOperation gains an inner full ctor variant `(…, DispatcherOperationTaskSource, bool useAsync, bool skipTaskAsyncStateMapping)` that routes to `InitializeWithoutMapping` when the bool is true and to the existing Initialize otherwise. Default false preserves the existing allocation behavior for every caller that exposes the op (BeginInvoke / InvokeAsync / LegacyBeginInvokeImpl / params-object[] BeginInvoke / DispatcherOperation<TResult>). * DispatcherOperation gains a new internal-sync Action ctor `(Dispatcher, DispatcherPriority, Action, bool internalSyncInvoke)` that propagates skipTaskAsyncStateMapping=internalSyncInvoke through to the inner ctor. * Dispatcher.Invoke(Action, DispatcherPriority, CancellationToken, TimeSpan) slow path (line 619 onwards) switches from `new DispatcherOperation(this, priority, callback)` to `new DispatcherOperation(this, priority, callback, internalSyncInvoke: true)`. Files modified: * src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/DispatcherOperation.cs — add new inner ctor (8-param) and new internal-sync Action ctor (4-param); the original 7-param inner ctor now delegates to the 8-param inner with skipTaskAsyncStateMapping=false. * src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/DispatcherOperationTaskSource.cs — add abstract `InitializeWithoutMapping` and the generic override. * src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs — switch the sync void-Invoke slow path to the new internal-sync ctor. Bench: *Dispatcher* filter — primary target is WindowLifecycleBenchmark.NegativeControlDispatcherInvoke, currently 320 B/op (post iter-095). The change should cut the Mapping allocation from every cross-thread Invoke(Action,…) call on that bench's hot loop. Expected: alloc Δ −24 B/op on WindowLifecycleBenchmark.NegativeControlDispatcherInvoke (well above the 16 B/op floor). Time Δ ~0 (no extra branches on the steady-state path — the ctor selector is resolved at compile time, the TaskSource override is a virtual dispatch already on the existing call site, and the default TaskCompletionSource<TResult>() ctor is strictly less work than the state-carrying ctor + Mapping allocation). No regression expected on DispatcherInvokeActionBenchmark.* (those benches hit the Send same-thread fast path which doesn't construct a DispatcherOperation at all — orthogonal to this change). No regression expected on DispatcherOperationInvokeBenchmark.* (those benches construct ops via reflection through the public-facing typed ctor and don't go through Dispatcher.Invoke's slow path — orthogonal). Safety: the only user-observable behavior that changes is Task.AsyncState on the synchronous Invoke(Action,…) slow path's hidden Task. That Task is never returned to user code — Invoke returns void, the op is allocated in the local frame of Invoke and goes out of scope when Invoke returns. The Task is reachable only through op._taskSource._taskCompletionSource.Task, and op itself is unreachable after Invoke returns. So the new null AsyncState is invisible to all user code that hasn't dug into Dispatcher internals via reflection. WPF internals that touch the Task (DispatcherOperation.Wait's `Task.GetAwaiter().GetResult()` for exception rethrow, InvokeCompletions' SetResult/SetException/SetCanceled, the cross-thread DispatcherOperationEvent path that subscribes to op.Aborted/Completed events rather than reading Task state) are AsyncState-agnostic and continue to work identically. Async-API paths (BeginInvoke, InvokeAsync, LegacyBeginInvokeImpl, params-object[] BeginInvoke, all DispatcherOperation<TResult>-creating overloads including Invoke<TResult>) continue to allocate the Mapping unchanged — they return the op to user code, so Task.AsyncState IS observable on those paths and the public IsDispatcherOperationTask / DispatcherOperationWait contracts must hold. The change is strictly additive: a new ctor surface for internal-sync, leaving every existing call site at the default-false skipTaskAsyncStateMapping behavior. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… for owner-less GetAsPathGeometry callers Four geometry types (Ellipse, Line, Rectangle, PathGeometry) called `new ByteStreamGeometryContext()` directly in GetPathGeometryData(), bypassing the existing StreamGeometryCallbackContext [ThreadStatic] pool. Each fresh context allocates its FrugalStructList<byte[]> store on the first AppendData, producing one SingleItemList<byte[]> per call. The 2026-05-11 deep-dive (autoresearch/deep-dive-2026-05-11/T2-dp-storage-churn.md) identified ByteStreamGeometryContext._chunkList as the *sole* source of the ~70 MB SingleItemList<byte[]> wedge in the take-open + playback scenarios. The StreamGeometryCallbackContext.DisposeCore path already amortizes its SingleItemList across pool cycles via DetachChunkListForPool; this commit extends the same pattern to the four owner-less callers. Add AcquireFromPool() / ReleaseToPool() static API on the base class with its own [ThreadStatic] slot, separate from StreamGeometryCallbackContext._pooled (since the base API has no StreamGeometry owner to pass). Reset uses the same ResetForReuse() helper used by the existing pooled path. On reentrant or unreleased call frames, the pool gracefully falls back to a fresh instance and the displaced ctx is GC'd — same failure mode as the existing single-slot pool. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Each call to UIElement.InputHitTest(Point, out, out, out) allocated four small heap objects: PointHitTestParameters, InputHitTestResult, and the two callback delegates (filter + result). At ~60 Hz cursor movement across a moderately deep visual tree, this fires ~5-50k times per scenario. The 2026-05-11 deep-dive (autoresearch/deep-dive-2026-05-11/T1-point-allocations.md) flagged this as the #1 contributor to the ~71 MB combined System.Windows.Point allocation budget across take-open + playback — estimated savings 30-40 MB. Three changes: - The filter callback's body uses only the `currentNode` argument and static UIElementHelper helpers — no `this` capture. Make it `private static` and cache one shared HitTestFilterCallback delegate as a static readonly field. - Cache a single PointHitTestParameters wrapper per thread via [ThreadStatic]. PointHitTestParameters.SetHitPoint() (already internal) mutates the inner Point before each VisualTreeHelper.HitTest call. - Add Acquire/Release pooling to the nested InputHitTestResult class. The HitTestResultCallback's delegate target IS the instance, so the pool stores the (instance, callback) pair to preserve binding across cycles. On rare nested reentrancy, Acquire falls back to a fresh instance — same single-slot pattern as the existing StreamGeometryCallbackContext pool. Result and HitTestResult are captured into locals BEFORE Release so the post-traversal iteration uses only stable values. VisualTreeHelper.HitTest is synchronous and consumes the parameters during traversal (no retention past return). The callbacks (filter + result) don't reinvoke InputHitTest, so reentrancy within one traversal is impossible. Reentrancy from the post-traversal contentHost.InputHitTest chain happens AFTER Release — pool slot is repopulated by the time recursion would run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ubles in non-Ideal text mode" This reverts commit 52b44a8.
MeasureOverride and ArrangeOverride allocated a fresh `DictionaryEntry[]`
every layout pass via `_zOrderMap.CopyTo(...)` to take a defensive snapshot
before iterating (callouts can mutate the map). In MotionCatalyst this
fires ~1675 times during take-open and dominates the residual WPF wedge:
* DictionaryEntry[] 178 MB take-open / 104 MB playback
* DictionaryEntry 140 MB take-open / 85 MB playback
Combined 508 MB across the two scenarios — 67% of the take-open trace's
total allocated bytes after the T1/T2 big-wins landed.
Stack attribution: single call site, attributed via GCAllocationTick_V4
stacks in profile-output/take-open/take-open.nettrace. See
autoresearch/t4-stack-attribution.md for the full trace.
Fix: snapshot the value list directly into a pooled `object[]` field via
`_zOrderMap.GetValueList().CopyTo(...)`. `SortedList.GetValueList()` returns
a cached `IList` over the internal values array (one-time alloc), and its
`CopyTo` does a direct `Array.Copy` of the values — no DictionaryEntry
boxing. The buffer is shared between Measure and Arrange because they
never overlap in a single layout pass. Pattern matches the existing
`_keysSnapshotBuffer` pool used by UpdateAdorner.
Apples-to-apples (same env, candidate vs candidate-with-fix):
take-open: DictionaryEntry[]+DictionaryEntry 318.8 MB -> 0 MB (-100%)
totalAllocBytes 616 MB -> 299 MB (-51%)
renderFrameP95Ms 10.55 -> 9.93 ms
(playback re-baseline was unstable in this run — captured an idle window
with only 876 render passes vs 18169 in the prior; needs a clean rerun
to validate, but the alloc-type targets are by construction equally
eliminated on every path through MeasureOverride/ArrangeOverride.)
oysteinkrog
force-pushed
the
feat/promote-if-authored-perf-opts
branch
from
2f45085 to
7831813
Compare
oysteinkrog
changed the title
oysteinkrog
pushed a commit
that referenced
this pull request
May 16, 2026
Commit 7831813 ("wpf-perf(big-win T4): pool AdornerLayer._zOrderMap value snapshot") shipped a per-instance object[] snapshot buffer shared between MeasureOverride and ArrangeOverride to eliminate ~170 MB of per-pass DictionaryEntry[] allocations during MotionCatalyst take-open. Defect: Adorner.Measure / Adorner.Arrange callouts can re-enter the same AdornerLayer's MeasureOverride/ArrangeOverride via a nested layout pass. A naïve shared field lets the inner call's CopyTo overwrite the outer pass's snapshot, and its terminal Array.Clear nulls the slots the outer is still iterating — the outer then reads a null reference and the layout throws, leaving MotionCatalyst with a completely blank canvas on take-open. Fix: lease pattern. Each call captures the current field value into a local, immediately nulls the field (so any re-entrant call allocates its own buffer rather than aliasing), iterates on the local, and at end of pass restores its buffer to the field — keeping whichever buffer (own or the one a nested call left behind) is larger. Steady state on the non-re-entrant path remains zero-allocation: the field holds the grown buffer, every subsequent call leases-clears- copies-iterates-clears-restores in place. Re-entrant calls pay one object[] allocation per nesting level, matching the worst case of the pre-7831813a baseline. Validated end-to-end via MCP UI screenshots on MotionCatalyst: - HEAD before fix: take-open shows fully black canvas - HEAD + this fix: identical to vanilla upstream/release/10.0 (Carl Hansen golf swing, Frame 0/1240, both video viewports rendered, Pressure & Stance heatmap, Launch Monitor, all data boxes populated, playback toggles cleanly) All 358 perf commits in PRs #1-#4 preserved.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Promote 43 IF-authored perf optimizations from the
wpf-perfintegration branch ontoif/main, so the next10.0.0-if.<N>nuget contains both upstream cherry-picks AND our own work.Currently published nugets (10.0.0-if.72 etc.) contain only the 38 upstream community cherry-picks (h3xds1nz et al.). Zero IF-authored optimizations have ever shipped, even though 30+ have been developed and validated on
wpf-perf.Net change
src/)Categories (no overlap with upstream picks)
UIElement.InputHitTestpool,ByteStreamGeometryContext[ThreadStatic] pool for owner-lessGetAsPathGeometry,AdornerLayer._zOrderMapvalue-snapshot pool, ThousandthOfEm text-mode realpoint reuse.OnLayoutUpdatedfast path,Visual.TryTransformToAncestorAsMatrixinternal fast path + AdornerLayer caller, dirty-bit guard aroundAdornerLayer.UpdateAdornerwalk,removeList+keys snapshot pool,branchNodeStack[ThreadStatic] inUIElementHelper.wpf-arautomated-research iterations (33): geometry parser tightening (iter 6/20/23/25/26/27/45/47/49/50/55),CulturePreservingExecutionContextpool + culture-write fast path (iter 28/29/39/57/66),StreamGeometryCallbackContext+AbbreviatedGeometryParser[ThreadStatic] pools (iter 32/33/34),Geometry.ShrinkToFituninitialized array (iter 36),AbbreviatedGeometryParserstruct conversion (iter 35),ReadWriteDatastraight-line fast path (iter 45),Clock.ComputeEventsin-placeTimeIntervalCollectionrebuild (iter 74),HwndWrapper/HwndSubclassmicro-hoists + lock-freeDispatcher.FromThread(iter 82/83/85),Window.ShowDialogtriple-pool (_threadWindowHandleslist,EnumThreadWindowsstatic-delegate,DispatcherFramepool) (iter 88/89/90/92),HwndStyleManagerper-Window pool (iter 87),MonitorEnumProcstatic-delegate-with-TLS (iter 93-window),EventHandlerlifecycle caches (iter 91),DispatcherSynchronizationContextper-priority cache +PushFrameImplreuse (iter 86/93),PriorityQueue<PriorityItem<T>>pool (iter 94),DispatcherOperationEvent[ThreadStatic] pool (iter 95), lazyDispatcherOperationTaskSource+DispatcherOperationTaskMappingskip (iter 96/97),Dispatcher.WrappedInvokeno-handlers fast path +ExceptionWrapper.TryCatchWhensplit (iter 62/98).What was excluded
wpf-ar(bd-XXX, …)) — research workflow infra, not perf code.8a96e13ce perf: re-enable PresentationFramework in autoresearch allowlist— pure tooling/python/ps1, nosrc/impact.254b6671b PresentationCore: layout-perf instrumentation + RequerySuggestedEvent fix—LayoutPerfTraceLoggeris debug ETW telemetry (would ship to consumers in a perf nuget); the bundledRequerySuggestedEventManagertypeof fix already landed onif/mainvia0b42d180f.How the source was reconstructed
Cherry-picked from
wpf-perfontoif/mainin chronological order. The "active set" was derived by walking commit subjects with apply/revert tracking and validated against thegit diff origin/if/main..wpf-perf -- src/net delta. After all picks, the only residual diff between this branch'ssrc/andwpf-perf'ssrc/is the inverse of the 15 upstream PRs that landed onif/mainafterwpf-perfwas last synced (cherry-pick batch h3xds1nz-2026-05-01) — meaning this branch is a strict superset of IF-authored work.Test plan
build.ymlruns green (Python lint, YAML lint, WPF arcade build on x64+arm64, 22-scenario NUnit smoke, BenchmarkDotNet perf gate ≤5% / >15% fail).if/mainbaseline — expect uniform improvements (these are the gains the gate was designed to surface).[DllImport,unsafe, orBinaryFormatterintroduced (hard-fail patterns). Heavy use of[ThreadStatic]pools and stack-allocation patterns; review for leak edges (pool refill in finally, capacity caps, null-out of pooled refs).Follow-up after merge
Tag
if-10.0.<next>to triggerrelease.yml→ human approval atwpf-nuget-publish→ new nuget published to nuget.org with both upstream picks AND IF-authored opts. Consumer inInitialForce/ScDesktop(currently pinned to10.0.0-if.72) can then bump the package reference to pick up the wins.🤖 Generated with Claude Code