Memory Measurement Method

Ferroni keeps memory comparison separate from the timing-oriented battle_bench suite.

Current scope

• Full committed TypeScript TextMate grammar from benches/grammars/typescript.json
• Two isolated processes:
  • battle_mem_rust
  • battle_mem_onig
• Two phases per engine:
  • compile: build the full scanner from the committed TypeScript grammar
  • scan: run one scanner search from the start of each line in a large deterministic TypeScript source

Exact external input revisions live in benches/battle_inputs.toml.

Why separate harnesses

Criterion is good for throughput and latency, but poor for memory attribution. For memory comparison we want one engine per process and explicit phase boundaries, otherwise Rust and Oniguruma allocations get mixed in the same RSS sample.

What is reported

Each harness prints one RESULT line per phase:

• compile: peak RSS through scanner compilation
• scan: peak RSS through compile + first-match scanning across the whole file

The peak comes from getrusage(RUSAGE_SELF).ru_maxrss inside the process. On macOS this is reported in bytes; on Linux the harness normalizes the kernel value from KiB to bytes.

Running it

./scripts/run-battle-memory.sh

Run this on a quiet machine after a fresh restart if you want numbers suitable for publication.

Latest local sample

Measured on 2026-09-23 at commit 2f109a75 on a MacBookPro18,1 (Apple M1 Pro, 32 GB) running macOS 27.0 (26A428) with rustc 1.98.1 (48a229cea 2026-09-01), against Oniguruma f95747b4 built from a local checkout via FERRONI_ONIGURUMA_DIR. The two harnesses were built and run the way ./scripts/run-battle-memory.sh does, without its source-download step. Each value is the median of three runs; the runs stayed within about 1% of each other.

Rounded for README communication, both engines are effectively in the same memory range at about 15 MB peak RSS on this workload.