Rust S-Expression Phase 1 Corpus Measurement

Decision

The named-corpus performance and peak-memory harness is accepted as the Windows measurement baseline. It closes the implementation and local evidence portion of the Phase 1 corpus-measurement task. Release floors remain unratified until an independent Linux run reproduces the harness and the parser promotion review accepts explicit budgets.

Method

Three promoted inputs are pinned by corpus-relative path, byte length, file SHA-256, and the content-addressed corpus archive SHA-256.
Rack builds the test-only runner once in release mode, then invokes the executable directly so Cargo and compilation memory are excluded.
Each tier runs three isolated processes for parse-only and full semantic-roundtrip operations. The best time, median time, all raw runs, and maximum sampled peak RSS are retained in transient evidence.
Parse-only holds the source and one generic tree. Semantic roundtrip holds source, canonical output, both trees, and second output long enough for the parent sampler to observe their process peak.
Every roundtrip proves parse, build, reparse, tree equality, and byte-stable second output. The dependency-free sampler uses native process counters on Windows and /proc high-water marks on Linux.

Windows Evidence

Tier	Input	Operation	Best time	Peak RSS	Peak/input
Small footprint	7,977 B	Parse	0.293 ms	4.35 MiB	baseline dominated
Small footprint	7,977 B	Roundtrip	0.486 ms	4.32 MiB	baseline dominated
Medium schematic	996,306 B	Parse	9.885 ms	12.91 MiB	13.58x
Medium schematic	996,306 B	Roundtrip	34.635 ms	24.73 MiB	26.03x
Large board	71,556,836 B	Parse	584.927 ms	506.58 MiB	7.42x
Large board	71,556,836 B	Roundtrip	2,247.323 ms	1,136.86 MiB	16.66x

These values came from Windows 11 on an AMD64 32-logical-CPU host using Rust 1.95.0. They are evidence from one run series, not portable limits.

Interpretation

Throughput is already useful, but full generic-tree memory is material. The large parse-only path peaks at about 7.4 times input size, while the two-tree oracle intentionally reaches about 16.7 times input size. This supports the existing architecture decision: the generic tree remains a compatibility and validation path, while promoted converters and typed readers must use selective spans or direct typed views rather than allocating the complete generic tree.

Select-All Sorting Evidence

A separate non-default measurement feature times form discovery and the final source-order sort independently. Five release runs per scanner and corpus tier show that sorting is material on the large board:

Tier	Selected forms	Scanner	Best scan	Best sort	Sort fraction
Small	350	Memory	0.121 ms	0.017 ms	12.4%
Small	350	Stream	0.173 ms	0.018 ms	9.6%
Medium	41,192	Memory	15.438 ms	1.496 ms	8.8%
Medium	41,192	Stream	19.040 ms	1.554 ms	7.5%
Large	2,124,874	Memory	772.026 ms	166.160 ms	17.7%
Large	2,124,874	Stream	1,021.759 ms	165.172 ms	13.9%

This cost is recorded in a focused backlog issue for possible source-order emission without the final O(k log k) sort. It does not block the current functional port; the parser promotion review should promote the optimization only if ratified budgets or a real consumer workload require it.

Retained Gates

Run the same hashed cases on Linux before ratifying floors.
Set budgets only in the parser architecture/promotion review.
Keep the measured selected-span sorting cost visible during budget ratification.
Measure path ownership and selector scaling separately.
Keep streaming-select, source-patch, and browser/WASM transfer as independent ledger tasks.
Do not authorize typed-model expansion until every Phase 1 dependency closes.