Profile unchanged VS Code CSS and visual-tree workloads with bounded performance gates

[wieslawsoltes]

Current performance checkpoint — 21 September 2026

Focused PR #891 merged at WebScene d3c030fa. The 20-run exact unchanged-Code-OSS gate after this CSS invalidation optimization painted under two seconds in 20/20 trials (p50 1,828.19 ms; p95 1,860.12 ms), while preserving model and computed-style checksums.

A later #252 workspace probe exposed an observer-induced refresh before the initial Explorer settle. Removing only that probe refresh gives exact models/rows and first-child paints of 1,621.87, 1,717.05, and 2,955.18 ms across three runs. The last run became workspace-ready at 1,853.78 ms, before provider activation, and still fails the absolute two-second gate. Product/runtime cold-start scheduling needs attribution; do not infer a CSS bottleneck or claim this diagnostic change as an engine fix. Source contract tests pass 25/25. Evidence: vscode-demo/docs/validation/workspace-first-child-timing-d3c030fa-20260921.md.

This issue stays open for Command Palette, Settings, Explorer interaction, terminal, panel churn, resize, hover, idle CPU, memory, lifecycle, scene publication, and matched browser/native workloads with bounded product-neutral gates. Start the next focused WebScene fix from a measured engine stage.

Parent tracker: #235

Problem

Microbenchmarks alone do not identify which CSS and visual-tree paths dominate unchanged VS Code. We need repeatable product workloads that point back to product-neutral engine fixtures and prevent CSS fixes from shifting cost into layout or scene publication.

Proposed work

• Capture bounded counters for editor startup, Command Palette, Settings, Explorer expansion, terminal attach/detach, panel open/close, resize, hover, and repeated class mutation.
• Record selector-index probes, matched rules, recascade scope, layout roots/nodes, scene nodes/publications, allocations, CPU, latency, and memory.
• Correlate each expensive path with a minimal product-neutral benchmark before changing WebScene.
• Use repeated A/B or ABBA measurement with semantic checksums and stable workload counts.
• Retain compact JSON summaries; remove large superseded traces/artifacts.

Acceptance

• Each scenario has a versioned workload and explicit budget.
• Browser/native visual and computed-style results remain equivalent.
• Every proposed optimization names the measured bottleneck and product-neutral regression.
• Results distinguish idle, mutation, layout, paint, and publication costs.
• [Epic] CSS features, compatibility, validation, and performance #235 is updated after every profile and disposition.

This work consumes #148 as the invalidation baseline and #234 only if its cumulative gates pass.

Current focused results — 19 September 2026

Seven exact no-op scheduling/visual-tree guards are merged through WebScene b100d6f: custom-property writes #549/#550; ID writes #551/#552; data/ARIA #554/#555; canonical tabIndex #556/#557; empty replaceChildren #559/#560; empty DocumentFragment append #562/#563; and empty textContent clear #565/#566.

The narrow source-backed audit is complete. General attribute/cssText/reparent shortcuts remain excluded where observable declaration, MutationObserver, custom-element, focus, selection, adoption, identity or event semantics could differ. New work must start from measured current product traces.

Only git diff --check ran. Authored high-count regressions and Code OSS A/B/ABBA, cascade/layout/scene counters, idle CPU, terminal attribution, pixels, package, lifecycle, memory and physical performance gates remain scheduled and unexecuted.

[danwalmsley]

Coordination from #245: starting read-only full resize-stage profiling on the existing product-neutral native-resize-cadence fixture and Spotify probe, using production head 66af278. This is the remaining original Spotify CSS-plan acceptance, not a duplicate implementation of the VS Code scenario harness or layout algorithms. The existing Avalonia cadence probe is headless CPU/draw-callback evidence only; it cannot prove physical presentation. Any identified broader cascade/layout change will be recorded and coordinated here/#240 before implementation. Structural mutation changes remain #245’s lane.

[danwalmsley]

Resize profiling update from #245: 3488758c / recorded evidence fixes the existing native-vs-Chrome workload mismatch (sawtooth vs triangle) and rejects physical-presentation qualification from headless callbacks. This is shared benchmark validation, not a competing VS Code scenario implementation. Production traces locate generic-fixture work mainly in tree/intrinsic layout; live Spotify through Avalonia shows significant retained-draw cost, but that is not evidence for the AppScene demo. The exact LLVM 22.1.8 closure is now available locally, and 5e9b0d1 fixes the custom compiler-root propagation prerequisite. Native-demo profiling remains next; no broad layout algorithm or cache change has been made.

[danwalmsley]

Native Spotify profile disposition from #245: the LLVM 22.1.8 SDK/consumer gate passed at 5e9b0d1, but the actual AppScene attempt is rejected as a resize baseline. Its 40-second report had readyState complete but zero cards, links and images; session bootstrap errors were logged. The programmatic resize driver separately failed with AXError. Presentation/sample traces from that empty workload must not be used for a speed claim. The evidence is recorded in docs/validation/css-resize-stage-profile.md at current pushed head 14ca683, now integrated with main b81f594. The independent sibling-detachment work remains inside #245’s structural lane; no layout algorithm, cross-frame cache or VS Code scenario implementation was added.

[wieslawsoltes]

New unchanged-product performance evidence on exact merged inputs:

• 20/20 launches were functionally exact.
• First-child Explorer paint: 2,164.26 ms p50 / 2,262.03 ms p95 / 2,263.77 ms max; 9/20 within the 2,000 ms bound.
• The distribution is bimodal: fast launches around 1,829–1,900 ms and slow launches around 2,164–2,264 ms.
• Five-cycle tracing correlates slow launches with management-socket task queue delay (786–839 ms p95 versus 548 ms in the passing trace), while Blob conversion remained below 0.1 ms and FileReader maxima remained about 38–48 ms.
• Increasing the worker task slice from 4 ms to 8 ms regressed p50/p95 paint and was discarded.

This narrows the next #243/#280 implementation to management-channel scheduling and repeated cascade/layout/publication work during early extension initialization. The rejected candidate is documented so it is not repeated.

[wieslawsoltes]

A second targeted candidate removed the intermediate Uint8Array and JavaScript slice() for WebSocket binaryType="arraybuffer" delivery.

The focused WebSocket/FileReader suite passed: exact Blob and ArrayBuffer bytes, 100 cross-source fairness cycles, settled heap, protocol timing, and FileReader ordering. The unchanged-product 20-launch gate did not improve:

• exact functionality: 20/20;
• within 2,000 ms: 9/20, unchanged;
• resolve: 914.63 ms p50 / 1,137.48 ms p95;
• paint: 2,215.91 ms p50 / 2,273.17 ms p95 / 2,281.95 ms max, versus clean 2,164.26 / 2,262.03 / 2,263.77 ms.

The candidate was discarded without a commit or PR. This rules out the ArrayBuffer conversion copy as the owner of the bimodal delay. Next work stays focused on protocol callback work and the layout/scene publication boundary.

[wieslawsoltes]

21 September exact-head diagnostic: unchanged Code OSS 645f29cc, WebScene 5b4739c8, AppScene 36d7a82e. During the controlled Markdown-preview native acceptance run, the real remote workspace and README file lifecycle completed byte-exactly. Two preceding native launches missed the existing 2000 ms Explorer first-child paint bound at 2198.78 and 2318.83 ms; the final run passed. This is intermittent cold-start evidence, not a passing repeated performance gate. The accepted 20/20 direct-subject run remains the earlier isolated measurement, and further source attribution/repeated cold runs are needed before closing #252/#243. Local logs: vscode-demo/build/appscene-webview-398/native-preview-36d7a82-frame-probe.log, native-preview-36d7a82-frame-probe-rerun.log, and native-preview-36d7a82-final-diagnostic.log.