Performance and evidence
Measurements you can interpret.
Use-case timings come from the running recipe. The private transaction and catalog recipes have separate Node/WASM references with 250,000 verified records. The historical Apple Health file-to-file qualification is preserved below. The large XML page shows only your browser run. Browser timings and reference RAM values are never mixed.
Engine memory budget
The large XML control configures maxMemoryMB: a budget for text-engine record and output payloads, excluding caller-owned data and runtime overhead. The SDK interprets its MB setting in units of 1,048,576 bytes. It is not a total browser RAM cap.
UI responsiveness
FPS samples main-thread animation frames during active processing. It measures interface responsiveness, not parser throughput. Measurement pauses when the document is hidden. Display refresh rate and browser scheduling affect the result.
Live application memory estimate
The XML graph uses measureUserAgentSpecificMemory when the browser supports it in a cross-origin isolated context. It estimates the page and its workers, rather than only WASM allocation or the main-thread heap. A pre-processing baseline is requested before worker startup; after five seconds processing can begin without a baseline. Late baseline results are discarded. Subsequent non-overlapping samples include measurement overhead in elapsed timings. The last reading and change from baseline are estimates, not exact converter attribution or OS process RAM. Sampling stops at completion or cancellation; brief runs may finish before any in-run reading. Garbage collection affects values and sampled peaks can miss short spikes. Unsupported or denied measurement is explicitly unavailable.
Peak RAM
The browser runner does not expose a total RAM measurement. JavaScript heap excludes important worker, WASM and browser allocations. The downloadable Node runner samples process RSS every 10 ms and during output writes, reports the baseline and additional peak, and can miss shorter spikes. This is sampled process memory, not a configured container limit.
Throughput
Input bytes divided by elapsed wall time, in MiB/s. Awaited output and deliberate sink delays are included. Local synthetic fixture generation is incremental and included in live sample timings. The Apple Health file benchmark excludes generation; hosted browser runs include network time. Input and output byte counts may differ substantially.
Time to first row
Time from starting the run to the first transformed record callback. The browser starts a fresh worker for each run; initialization and asset-loading work for that run are included, with network caching dependent on the current browser. This is a callback time, not a persisted endpoint acknowledgement.
Total time
The processing interval includes reads, transforms, serialized output and awaited sink work. Node includes closing its output file. The large XML page measures wall time from worker startup until the main thread receives completion (the baseline measurement is excluded), including worker startup and result delivery. During pause or failure, the last progress interval is partial rather than a completed result.
OOM threshold
The current reference reports the largest workload tested successfully for each recipe. “Not reached at X MiB” is a passing workload, not a located failure threshold. An evidence-bearing failure boundary needs the last passing and first failing fixture, exact runtime and parser versions, hardware, memory controls, maximum record size, repeats and the actual failure category. A JavaScript string-length error is distinct from exhausting memory. Destructive sweeps must run in an isolated benchmark environment, never on a visitor’s device.
Bounded working memory
Incremental reads are only one part of the pipeline. These examples use scenario-specific transforms, limit records and batches, await the output sink and retain only five small records plus a short output preview. Collecting all rows, building a final Blob, large individual records, deeper nesting, global transforms or concurrent jobs changes memory requirements.
Reference qualification
The smaller references use 250,000 records and a 64 MiB V8 old-space setting, not a total process cap. Apple Health uses a separate file-to-file benchmark with an independent CSV row check and a memory timeline. Its fixture is a repeating synthetic record cycle. Systematic file-size sweeps and 128 / 256 / 512 MiB container profiles remain separate qualification work. Publish exact fixture bytes, decoded characters, structure, package identity, backend, environment, output digest, complete record counts and failure evidence with each result. Node container results do not establish Cloudflare Workers or other serverless compatibility.
Historical Node.js + WASM file benchmark
Completed file benchmark · Node.js + WASM
11.48 GB processed. Every output row checked.
45,000,000 health records → 4.71 GB of CSV. These recorded results are separate from your live browser run.
- Peak RAM
- 197.78 MiB
- Sampled total process RSS.
- Throughput
- 11.11 MiB/s
- File read, conversion and awaited writes.
- Time to first row
- 37.52 ms
- First transformed record callback.
- Total time
- 16.42 min
- Includes closing the output file.
- OOM threshold
- Not reached at 11.48 GB
- The failure boundary was not searched.
The line shows 10-second samples; peak RAM also includes 10 ms samples and output-write samples. Process RSS includes the runtime and WASM. Baseline: 73.4 MiB.
Environment, dataset and reproduction
v24.19.0 · win32/x64 · 13th Gen Intel(R) Core(TM) i7-13650HX · 2026-09-09
One Node/WASM file-to-file run. Sampled total process RSS every 10 ms and at awaited writes; timeline every 10 s. Input generation, imports and independent CSV verification excluded. Output SHA-256 and file close included. No process memory cap or OOM sweep. Synthetic 4,096-record cycle repeated to the stated size.
The fixture contains 11,480,416,388 uncompressed bytes. A 4,096-record cycle is repeated to stress file size; it is not a real health history. Browser timings include worker startup and, for the hosted file, the network.
XML SHA-256: fd08ca760b0d680435ea043c091ca8b861ff1b1ca79fadef641dacffc983431d
CSV SHA-256: c0cfb3743872940837368ed5fe372a1937635536c3826ed7425bcb7132d07f82
Download results and memory samples · Download the standalone generator
Generate the same file with node generate-apple-health.mjs 45000000 health.xml, then use the Node.js recipe below. The browser and Node.js share the same mapping.
For the full verification harness, run node scripts/qualify-apple-health.mjs from apps/web in the matching checkout. It writes XML and CSV into .tmp/fixtures and verifies every CSV row independently.
Schema reference: apple-health-insights example generator. Our generator is an original bounded-memory implementation.