Measured, archived, reproducible
Benchmarks
This page summarizes recorded repository evidence. The raw reports remain the source of truth because a clean headline without its machine, runtime, warmup, workload, allocations, and caveats is just marketing with decimals.
Report families13Checked-in archives through August 27
Strategic backendSDL3 GPUCompared directly with WindowsDX
Latest visual diff0 pxTwo 1600 x 900 Aspect scenarios
Honest frame gateREDLatest SDL3 16.6667 ms target remains red
01 / Current renderer evidence
SDL3 GPU versus WindowsDX
The same retained Prism command list rendered a 256 x 144 scene with Gaussian blur, emboss, and hue/saturation. Each backend warmed for 12 frames and measured 96 submitted and presented frames on the same machine.
WindowsDX CPU frame6.9028 ms96 measured frames
SDL_GPU CPU frame6.8673 ms0.9949x WindowsDX
SDL_GPU allocation+7.1%229,163 B/frame
Fallbacks0Both backends
Presented retained workload
Backend comparison
Lower is better for time, allocation, and resource use. Counters explain the work; they do not magically make different backend pipelines identical.
| Metric | WindowsDX | SDL_GPU | SDL_GPU / WindowsDX |
|---|---|---|---|
| CPU frame time | 6.9028 ms | 6.8673 ms | 0.9949x |
| Managed allocation | 214,037 B/frame | 229,163 B/frame | 1.0707x |
| Peak Prism GPU resources | 2,359,056 B | 3,047,144 B | 1.2917x |
| Last retained-frame Prism passes | 1 | 2 | 2.0000x |
| Last Prism CPU submit | 126.2 us | 284.2 us | 2.2520x |
| Active transient surfaces after frame | 0 | 0 | Equal |
The 0.9949x CPU-frame ratio is below the plan's 1.25x investigation threshold. SDL_GPU still used one extra presentation pass, 688,088 more peak Prism-resource bytes, and 7.1% more managed allocation. Those costs stay recorded instead of disappearing behind the headline.
02 / Real application evidence
Frame budget and Aspect migration
The August Aspect comparison used the real SDL3 Presentation tour, eight cycles, 45 frames per chapter, and a 16.6667 ms target. The target was RED before and after the migration, so the valid claim is comparative, not a fake pass.
Same SDL3 Presentation workload
Aspect migration comparison
The higher processed count proves generated markup moved onto the canonical Aspect engine. Absolute scheduled Aspect cost remains visible beside that architectural change.
| Metric | Baseline | Final |
|---|---|---|
| Warm scheduled Aspect mean | 0.000381 ms | 0.001877 ms |
| Warm scheduled Aspect p99 | 0.0005 ms | 0.0726 ms |
| Scheduled Aspect maximum | 0.0889 ms | 0.1766 ms |
| Processed Aspect elements | 56 | 172 |
| Mean allocation per frame | 643,430 B | 638,750 B |
Visual conformance
Application-owned captures
Both images were captured through Window.SaveScreenshot.
| Scenario | Pixels | Changed | Result |
|---|---|---|---|
| Aspect Studio | 1,440,000 | 0 | GREEN |
| Build-Time Markup | 1,440,000 | 0 | GREEN |
Earlier WindowsDX gate
July frame-budget repair
This is a different backend and run. It must not be substituted for the later SDL3 result.
| State | Global maximum | Over budget |
|---|---|---|
| RED baseline | 52.880 ms | 113 frames |
| Final WindowsDX run | 14.763 ms | 0 frames |
03 / Build-time and editor paths
Language core and Visual Studio
The language baseline measures parsing, local edits, semantic binding, and warm queries. The Visual Studio archive uses a hidden Community Experimental Instance and records cold activation, editor latency, soak memory, and resilience.
21,123-character real document
AspectChapterView.crn
Forty measured iterations after eight warmups, Release, .NET 8.
| Operation | p95 | Max | Allocated |
|---|---|---|---|
| Parse cold | 1.386 ms | 5.505 ms | 285,384 B |
| Parse warm | 1.447 ms | 8.017 ms | 279,296 B |
| Incremental edit | 1.534 ms | 1.925 ms | 369,984 B |
| Semantic bind | 14.923 ms | 15.999 ms | 2,479,080 B |
| Warm query | 0.062 ms | 2.076 ms | 464 B |
Visual Studio Community 18.0
Cold and full-solution observations
Cold gates apply where a budget is shown. Warm editor presentation rows are recorded observations, not relabeled server-only passes.
| Workspace | Metric | Value | Budget | Result |
|---|---|---|---|---|
| Fixture | Provider activation CPU | 15.625 ms | 100 ms | GREEN |
| Fixture | Server ready cold | 833.196 ms | 2,000 ms | GREEN |
| Fixture | First completion cold | 1,357.454 ms | 2,500 ms | GREEN |
| Cerneala.slnx | Server ready cold | 964.291 ms | 2,000 ms | GREEN |
| Cerneala.slnx | First completion cold | 1,922.658 ms | 2,500 ms | GREEN |
| Cerneala.slnx | Editor completion p95 | 228.241 ms | Observed only | RECORDED |
The soak covered 100 document open/close cycles and 1,000 editor changes. The resilience matrix covered server restart, solution reload, extension disable, unavailable server, and process cleanup. Raw JSON is stored beside the report.
04 / Retained runtime
RenderSurface2D, queues, Relay, and cache reuse
These reports cover different layers and different dates. The numbers stay separated by workload. The shared contract is that idle and reusable work should not quietly become tree scans, command storms, or allocation churn.
RenderSurface2D drawing API
Accepted August 24 baseline
BenchmarkDotNet ShortRun. Relative command-count and allocation invariants are the primary gates for the shortest manually invoked methods.
| Scenario | Mean | Managed allocation | Evidence |
|---|---|---|---|
| 1,000 individual point commands | 544.217 us | 0 B observed | Baseline |
| Immutable 1,000-point batch | 1.767 us | 0 B observed | 0.003x command time |
| Build 1,024-point polygon | 56.984 us | 234,130 B | Baseline |
| Record reusable path | 114.1 ns | 0 B | About 0.002x rebuild time |
| Rebuild text layout | 41.594 us | 39,009 B | Baseline |
| Reuse immutable text layout | Below measurement floor | 0 B | Zero-cost reuse result |
Queue Engine idle5.216 ns10,000-node tree, 0 B after warmup
UiRelay drain 1,02456.575 usInitial archive, 120 B/frame
WPF drain comparison97.78x9,361.66 us versus 95.74 us
Prism common instances-80.9%CPU cache-on delta, 0 B/frame
These are historical same-run results, not universal multipliers. Queue Engine 2.0 removed the tree-size dependency from warmed idle checks. The WPF comparison covers a deliberately narrow scheduling and drain contract, not the complete WPF Dispatcher feature set. Prism cache wins apply to stable retained scenes; dynamic scenes correctly record misses and their cost.
Complete recorded index
Thirteen report families, with their raw context
The website is a readable index. The checked-in Markdown, JSON, CSV, logs, screenshots, and BenchmarkDotNet output are the durable evidence.
- 01
Queue Engine 2.0
Idle checks, sparse snapshots, shared order, drain, rebuild, and detach. - 02
UiRelay
Scheduling, bounded drain, concurrent producers, and binding coalescing. - 03
WPF Dispatcher comparison
Two complete controlled runs and raw BenchmarkDotNet reports. - 04
Presentation frame budget
RED baseline, allocation investigation, three-run gate, and human visual confirmation. - 05
Prism filter catalog
Optimizer, passes, transient surfaces, CPU submission, and warm allocation. - 06
Prism cache-off baseline
Reference workload before retained pixel-cache reuse. - 07
Prism retained cache
Static wins, dynamic misses, deterministic counters, and memory budgets. - 08
Prism integration hardening
Timing matrix, preview scaling, eviction, failure behavior, and dogfood gate. - 09
Language core
Parsing, local edits, semantic binding, warm queries, and allocations. - 10
Visual Studio Community extension
Cold startup, warm editor paths, soak memory, and resilience. - 11
RenderSurface2D drawing API
Batches, shapes, state, strokes, paths, and text-layout reuse. - 12
SDL_GPU Prism comparison
Same-machine WindowsDX comparison with CPU, allocation, passes, and resources. - 13
Aspect unification
BenchmarkDotNet, deterministic metrics, frame budget, pixel diffs, API diff, and final verification.
How to read this
Evidence has boundaries.
These numbers describe recorded workloads on recorded machines. They are useful baselines and regression evidence, not hardware-independent promises about every game or application.
Archive families13Each linked above
Latest recorded evidenceAugust 27, 2026SDL_GPU and Aspect
Primary runtime target.NET 8SDK and machine vary by report
Timing harnessesBDN + runtime runnersNot every workload belongs in one harness
Visual captureWindow.SaveScreenshotApplication-owned screenshots
Raw evidenceRepository-ownedMarkdown, JSON, CSV, logs, and images
Compare within the recorded experiment
Before and after values are meaningful when machine, runtime, configuration, workload, and warmup are controlled. Do not combine unrelated reports into one fake leaderboard.
Cold and retained work are different
JIT, shader creation, uploads, cache promotion, and first-use resource work must remain visible. A warmed zero-allocation path does not prove cold startup is free.
Timings do not replace invariants
Tests separately guard idle traversal, exact-once dispatch, bounded backlogs, cache invalidation, resource cleanup, draw purity, and visual conformance.
Noise is not a root cause
Short runs can have broad confidence intervals. Reproduce on equivalent hardware, inspect counters and allocations, and only then assign ownership to a subsystem.