Repository navigation
Profile unchanged VS Code CSS and visual-tree workloads with bounded performance gates #243
Description
Activity
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.
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.
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.
- added sub-issues
on Sep 19, 2026 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.
A second targeted candidate removed the intermediate
Uint8Arrayand JavaScriptslice()for WebSocketbinaryType="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.
21 September exact-head diagnostic: unchanged Code OSS
645f29cc, WebScene5b4739c8, AppScene36d7a82e. 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, andnative-preview-36d7a82-final-diagnostic.log.
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
Acceptance
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.