perf(runtime): measure startup, execution and package costs #266

Own reproducible performance measurements and decisions about optional optimizations. This combines Windows V8 cost qualification with the conditional investigations previously scattered across #201/#203.

This is the sole active owner of audit IDs 53, 54, 56, 57, 58 from the archived #203. Original acceptance and evidence remain there. Correctness implementation belongs to #201/#249/#244/#269; dependency and package correctness to #213. Measurements may motivate a change in those owners, but do not duplicate their acceptance or waive invariants. Each item below includes its own behavioral verification; shared packaged-product/integration evidence is owned by #213.

Reviewed 8 October 2026: main 293f31f4; integration #218 at 3b1f7cd4. #255 merged through #247 into #218; #268 is also in #218. #218 remains open, so candidate changes are not on main or published.

Required measurement and optional research

Primary deliverable: measure the supported Windows V8 engine/cache costs with exact packaged inputs, actual GUCs, a matched control and retained raw results. Package-consumption CI is not performance evidence. Freeze the final candidate after #268: measure embedded default-off and explicit-fsync-on directory controls separately. Old 8db3bd88 packages and September strict/all-on experiments are historical baselines, not results for the new candidate.

Conditional audit items 53–54 and 56–58: reinventory and measure Node dispatch, parameter/parsing copies, repeated startup/resource materialization, optional Wasmer copy/frame-pointer/SIMD/start-image choices, and remaining SQL/PostGIS link/export cost. Main #216/#246 and #218's removal of 13 optional guest patches change the baseline. Do not revive retired shortcuts or precommit to implementing every experiment. A recorded no-benefit/not-worthwhile disposition closes a research lead.

Use the same methodology for preparation/copy/publication/serving-ready/first-query phases, cold/warm cache state and default/explicit-on storage comparisons. The concrete restore-metadata and Kotlin-encoding fixes remain #249/#269; this bucket supplies comparative evidence rather than a second implementation checklist. Retain existing September raw reports and detailed experimental findings via the historical section of #201.

Existing foundation

#255 bundles the engine and genuine SSE4.1 native-cache profiles, including the appropriate CET variant, while retaining Linux/macOS LLVM paths and normal SDK installation. Successful source CI run 37584874208 at 8db3bd8885c32a5ca546f9038fc04764ab56610b supplies frozen working packages and correctness evidence, not benchmark results.

Reuse the existing WASIX benchmark plans and methodology, src/benchmarks/perf/wasix-node, and existing artifact provenance/reporting. Extend only what is necessary for the Windows engine and directory measurements; avoid another benchmark framework or duplicate producer builds.

Acceptance

• Freeze the candidate commit and actual installed SDK/runtime/cache inputs. Record hashes, Wasmer/V8/WASIX/PostgreSQL versions, Node/Rust versions, runner/CPU features, selected cache profile, storage/settings and harness identity. Reuse those artifacts across repetitions.
• Measure cold-to-first-result, public open/first-query components, warm reopen/cache loading, directory reopen and close with consistent timing boundaries. Keep maintainer cache-production/compilation cost separate from consumer startup: the consumer contract still requires precompiled caches and no runtime compilation.
• Run varied INSERT/read/JSONB/mixed-transaction workloads and query RTT using existing result/checksum oracles. Use fresh independent processes, balanced comparison order, raw samples and an A/A noise control. Report medians/tails and shared-host limitations; do not silently pool incompatible runs.
• Record actual PostgreSQL settings for memory and directory runs. Measure the current embedded default-off policy and an explicit fsync-on directory control separately; record synchronous_commit and full_page_writes as well. Match configuration and execution ownership before using PGlite or another reference for ratios; PGlite's default fsync=off is not a durability-equivalent baseline. Linux/macOS controls must not be presented as measurements isolating only the engine or as proof of Windows speed.
• Measure process/engine memory and the complete compressed/installed package closure, including DLL, caches and private payload parts, without double-counting shared dependencies. Record distribution/licensing overhead and the cost of the cache variants actually selected on compatible hosts.
• Publish a concise conclusion linked to exact artifacts and raw reports: accepted costs, demonstrated regressions, and any measured optimization worth pursuing. Keep correctness-required patches even when they do not improve speed. Attribute a regression before proposing an optimization.

The recursion correctness gap is tracked in #201 (evidence archived in #265); benchmark success cannot close it. This issue does not independently change the selected storage policy or public SDK behavior, authorize silent consumer-side compilation on Windows, or revive unsupported Sys compiler support. Existing benchmark gates remain authoritative for their declared scope; descriptive Windows measurements must be labelled separately until their plans are qualified.

Completion

Publish the Windows cost conclusion and mark each pursued conditional lead as demonstrated benefit, rejected, or deferred with a reason. Keep required engine, filesystem and SQL semantics invariant; benchmark success cannot close a correctness issue. Further optimization is justified by the measurements, not required simply because it appeared in the old audit.