v1.1 Performance Report

Method

Measurements use five local runs and report the median. The benchmark-engine workload is a deterministic 1,000-iteration FakeBackend run driven by ScriptedTimingEngine; it measures framework work only, not hardware execution. The report workload renders JSON, Markdown, CSV, and HTML from that completed session.

Before and after

Workload	v1.0.1 median	v1.1.0 median	Change
Benchmark orchestration, 1,000 iterations	21.807 ms	12.855 ms	41.1% faster
Four-format report generation	24.066 ms	6.330 ms	73.7% faster
Repeated hardware inspection, same instance	2.197 ms	0.005 ms	99.8% faster
Register 1,000 independent plugins	12.535 ms	12.042 ms	3.9% faster

The fresh hardware-probe comparison varied with host state (2.507 ms before and 1.909 ms after), so it is reported as observational rather than attributed to code changes.

Profile findings

The v1.0.1 benchmark profile spent notable aggregate time repeatedly scanning execution observations for memory, CPU, GPU, and operation counts, and recomputing latency statistics in the metrics engine. v1.1.0 accepts already-computed benchmark latency statistics and collects all observation categories in one run scan.

Multi-format reports previously rebuilt the complete view and charts once per format. ReportViewBuilder.build_many now materializes shared session/chart content once and substitutes only per-format metadata. The invariant Jinja template is compiled once per process.

SystemHardwareInspector now caches static CPU, memory, and GPU probes for its lifetime, but continues to read thermal and power policy environment values on every inspection. Plugin registration no longer removes elements from the pending list repeatedly.

Compatibility

All changes preserve existing report formats, metric values, plugin lifecycle semantics, and hardware-profile fields. New optional latency_statistics input on CoreMetricsEngine.compute is backward compatible.