CHD, RVZ, ZIP, and 7z speed benchmarks

Compare native rom-weaver CLI conversion speeds with chdman, dolphin-tool, 7zz, and Info-ZIP using recorded timings and matching codec settings.

The suites below measure CHD, RVZ, 7z, and zip against their reference tools. Each suite measures both directions: compress and extract. Output size is recorded next to every timing.

These competitor comparisons measure the native CLI, not the browser app. They do not measure Z3DS conversion or patching against other tools. Results apply to the listed versions, inputs, and machine.

Comparison with similar tools explains the workflow differences beyond speed.

Summary

Ratios compare wall time. "2× faster" means the reference tool took twice as long. Results cover this corpus, not every file. Extraction is faster in all four formats. RVZ and ZIP compression are slightly faster. 7z compression is even with 7zz. CHD compression ranges from 8% slower to 20% faster. Output sizes match the references to within a fraction of a percent everywhere.

† The 7z extract timings include rom-weaver's default common-file filter. 7zz extracts those sidecar files. The multi-file result therefore measures the whole application path, not just the decoder. The filter writes 291–717 fewer bytes in this set.

Benchmarks in this repository

scripts/parity-check.mjs is the correctness counterpart. It checks that CHD, RVZ, 7z, and ZIP payloads round-trip through rom-weaver and their reference tools in both directions. It compares extracted payload bytes. Archive metadata and compression streams differ between tools, so it cannot compare archive bytes.

Method

scripts/bench-disc-tools.mjs walks a corpus directory. For each source it recognises, it builds two benchmarks: one compress and one extract. It hands both commands to hyperfine, which runs a warmup pass and then the measured runs.

A --prepare step deletes the previous output before each run, so every run starts clean. This matters for two reasons. rom-weaver extract stops rather than overwrite files already in the output directory. A reference tool that skipped a write because the target existed would be timed as instant.

Output size is recorded separately, from a single untimed execution of the same command.

The warmup run puts the source in the page cache. The measured runs then compare compression work, not first-read disk latency. On a machine without room to cache the whole source, the numbers describe an I/O-bound workload instead.

Sources under 1 MB are excluded by default (--min-size). At that size every tool here finishes in under 20 ms, so process startup dominates the measurement.

Settings

Both sides run at parity. Where the two tools already agree on a default, both are left alone. Where they do not, both are pinned to the reference tool's own default, never rom-weaver's.

Additional measurement conditions:

• Archive extraction is capped at one layer. rom-weaver unpacks archives found inside archives; 7zz and unzip stop after one. The harness passes --no-nested-extract so both sides do the same work.
• The 7z extract path keeps rom-weaver's default common-file filter. This skips sidecars such as provenance text files. 7zz extracts every member. Add --no-ignore to the rom-weaver command in the harness for a pure decoder comparison.
• The zip suite uses two reference binaries, zip to write and unzip to read, since Info-ZIP splits them.
• Sources under 1 MB are skipped (--min-size). A ROM corpus carries patch bundles and manifest fixtures that are not ROMs. --min-size 0 benchmarks everything.

Two chdman behaviors the harness works around

• Extraction is split across subcommands by disc type, and chdman does not pick one for you. extractcd handles CD and GD-ROM. extractdvd handles DVD. The harness reads the CHD's own metadata tag via chdman info (CHT2/CHTR → CD, CHGD → GD-ROM, DVD → DVD) and routes to the right subcommand. rom-weaver reads the same tag itself, so its side is one command for all three types.
• A wrong subcommand fails but still exits 0. Run chdman extractcd against a DVD CHD and it stops on an uncaught C++ exception, writes nothing, and returns success. Exit status alone would score that crash as an extremely fast run. Every measured command must therefore also produce a non-empty output.

Results

scripts/bench-disc-tools.mjs produced these results at the codec settings in Settings. Those settings pin both sides to the same codec, level, and block size, so the two tools do equivalent work.

Machine: a quiet 10-core arm64 machine, otherwise idle. Binaries: rom-weaver 0.8.0 built --release, against chdman 0.287, dolphin-tool, 7zz 26.02, and Info-ZIP. Date: 2026-07-26. Runs: three timed runs per command after one warmup; ± is the standard deviation across those runs.

The suites ran in two sittings: chd and rvz in one, then 7z and zip in a second after the archive corpus grew to include the 256 MB and 1 GiB ROMs.

One exception: the RVZ size columns were re-measured after #213, which changed how much padding RVZ compression detects. Their time columns are still from the original sitting. RVZ output is deterministic: three repeats produced bit-identical sizes. The size columns are therefore exact even though they and the time columns come from different runs. #213 touches only GameCube junk detection, so no other suite was affected.

The 7z tables below replace the earlier 7z results. They were rerun on 2026-08-04, after native LZMA2 writes and eligible LZMA1/LZMA2 reads moved onto 7-Zip's own LZMA SDK - the same coders 7zz runs. Filter chains, LZMA1 writes, and WebAssembly writes stay on liblzma.

The rerun used an Apple M1 Max, rom-weaver 0.11.1, and 7zz 26.02. Each command had one warmup and three measured runs. Hyperfine flagged outliers on the 32 MB and 256 MB compression rows, so those row-level timings are less certain.

Time change is rom-weaver's elapsed time minus the reference tool's, in seconds and as a percentage of the reference. Negative means rom-weaver finished sooner. Size change is rom-weaver's output relative to the reference's. Negative means smaller.

The corpus is not redistributable, so sources are identified by platform and disc type rather than by title. The same label means the same source everywhere in this document.

CHD vs chdman

Five commercial discs spanning all three CHD disc types: PS1 CDs with mixed data and audio tracks (CHT2), a Dreamcast GD-ROM (CHGD), and a PS2 DVD (DVD ).

Extract

rom-weaver extracted these discs 3.1–5.8× faster than chdman, 6 to 22 seconds sooner per disc.

Output sizes agree with chdman's to within 72 bytes on every disc. The difference is cue-sheet text - track naming and line endings - not image data.

Compress

Compression ranges from 8% slower to 20% faster across the four discs, with output up to 0.7 MB smaller.

RVZ vs dolphin-tool

Two GameCube titles. The .rvz sources are third-party dumps; the .iso compress inputs were produced by extracting them.

Extract (RVZ → ISO)

rom-weaver extracts these two discs 1.6–2.0× faster.

Compress (ISO → RVZ)

Times here are sub-second because most of a GameCube disc is pseudorandom padding. RVZ stores that padding as a seed instead of compressing it. Only the real payload, roughly 100–160 MB of a 1.46 GB disc, reaches the compressor.

Both directions are lossless. Extracting either tool's RVZ reproduces the source ISO's SHA-1 exactly, and the two extracted ISOs are byte-identical to each other.

GameCube A measured +8.38% before #213, which changed junk detection to read the GameCube filesystem table for file end offsets.

7z vs 7zz

LZMA2 at level 5 on both sides. The compress inputs are cartridge ROMs, 16 MB to 1 GiB. Disc images are excluded here because the chd and rvz suites already measure them. The .7z archives read back on the extract side do contain disc images.

Compress

The SDK encoder keeps compression even with 7zz: every row is within about ±7%, and the archives are 19–24 bytes smaller. The archive bytes are not expected to be identical, because the tools write different metadata. The parity check compares the extracted payload instead.

ROM_WEAVER_7Z_ENCODER=liblzma still selects the seeded liblzma encoder. The legacy encoder is not measured in this table.

Extract

The output size column counts bytes written by each tool. rom-weaver's default common-file filter skips sidecar files that 7zz writes, so its output is 291–717 bytes smaller on these rows. PS1 CD A contains eight track files plus sidecars. Its large lead (4.7×) combines multi-file extraction with that filtering. The other rows are 1.01–1.03× faster with rom-weaver, and they still include the same filtering difference.

For a pure decoder comparison, pass --no-ignore to rom-weaver's extract command in the harness. The portable decoder also optimizes repeated-byte matches; see the targeted measurements in vendor-code.md.

These numbers are arm64, where that loop needs no extra tooling. On x86-64 the loop is MASM assembly. The build only uses it when a MASM-compatible assembler is on PATH: the shipped Linux x86-64 (glibc) and Windows x86-64 builds have one, and x86_64-apple-darwin never does. A build without one keeps the C decoder, lands roughly where the old rows did, and says so in a cargo:warning. See Which platforms get the assembly decode loop for the full matrix.

zip vs Info-ZIP

Deflate at level 6 on both sides; zip writes, unzip reads.

Extract

rom-weaver extracts these archives 1.6–2.7× faster than unzip.

Compress

rom-weaver compresses 1.1–1.2× faster than zip, with output within 0.1% of Info-ZIP's.

Info-ZIP's run-to-run spread on the two largest compress inputs (± 1.4 s and ± 1.9 s) is wide, so those two percentages are not precise.

Reproducing

cargo build --release -p rom-weaver-cli
npm install --global chdman dolphin-tool   # or your distribution's packages
brew install hyperfine sevenzip            # zip/unzip ship with macOS

BENCH_CORPUS=/path/to/corpus mise run bench-chd
BENCH_CORPUS=/path/to/corpus mise run bench-rvz
BENCH_CORPUS=/path/to/corpus mise run bench-7z
BENCH_CORPUS=/path/to/corpus mise run bench-zip

All four tasks wrap one script. Call it directly for anything they do not expose:

node scripts/bench-disc-tools.mjs --suite rvz --corpus /path/to/corpus --runs 5

The corpus is deliberately not in the repository. These benchmarks need real ROMs and disc images, which are not redistributable. Point --corpus (or BENCH_CORPUS) at a directory of your own. The harness discovers sources up to three levels deep, so the usual one-directory-per-title layout works as-is. Each suite picks up only what it can use:

"ROM files" means .gba, .nds, .3ds, .cci, .sfc, .smc, .n64, .z64, .nes, .gb, .gbc. These cartridge dumps range from a 128 KB NES ROM to a 1 GiB 3DS image. Some of the larger ones only exist inside the corpus's own archives. Extract those once and the archive suites pick them up.

Flags:

report-<suite>.json records the host CPU, the rom-weaver version, the reference tool, the run counts, and for every case both tools' timings and output sizes.

A source one tool declines is recorded as a skip and the run continues.

Browser benchmarks

Run all browser-worker benchmarks with Vitest bench mode (from packages/rom-weaver-webapp):

npm run test:browser:wasm:bench

Run the suites that cover the same operations as the Python benchmark scripts:

npm run test:browser:wasm:bench:command-paths
npm run test:browser:wasm:bench:checksum-threading

Benchmark environment variables:

• Shared Vitest bench timing:
  • ROM_WEAVER_WASM_BENCH_TIME_MS (default 50)
  • ROM_WEAVER_WASM_BENCH_ITERATIONS (default 1)
  • ROM_WEAVER_WASM_BENCH_WARMUP_TIME_MS (default 0)
  • ROM_WEAVER_WASM_BENCH_WARMUP_ITERATIONS (default 0)
  • ROM_WEAVER_WASM_BENCH_OUTPUT_JSON (optional output JSON path)
  • ROM_WEAVER_WASM_BENCH_CLEAR_FIXTURE_CACHE (1 clears the persistent OPFS fixture cache before setup)
• bench-command-paths.py benchmark suite (tests/wasm/browser-worker-client.bench.mjs):
  • ROM_WEAVER_WASM_BENCH_COMMANDS (default compress,extract,checksum,patch-create,patch-apply)
  • ROM_WEAVER_WASM_BENCH_CONTAINER_FORMATS (default chd,rvz,7z,zip,tar,tar.gz,tar.bz2,tar.xz,z3ds,gz,bz2,xz,zst)
  • ROM_WEAVER_WASM_BENCH_PATCH_FORMATS (default all)
  • ROM_WEAVER_WASM_BENCH_CODECS (default all; filters codec cases)
  • ROM_WEAVER_WASM_BENCH_CHECKSUM_ALGOS (default all)
  • ROM_WEAVER_WASM_BENCH_CHECKSUM_MODES (default raw)
  • ROM_WEAVER_WASM_BENCH_CHECKSUM_COMBO_ALGOS (default crc32,md5,sha1, none to disable)
  • ROM_WEAVER_WASM_BENCH_SOURCE_MIB (default 128)
  • ROM_WEAVER_WASM_BENCH_PATCH_SOURCE_MIB (default 128)
  • ROM_WEAVER_WASM_BENCH_THREADS (default 4)
• bench-checksum-threading.py benchmark suite (tests/wasm/browser-checksum-threading.bench.mjs):
  • ROM_WEAVER_WASM_BENCH_THREADING_ALGORITHMS (default crc32c,crc16,adler32)
  • ROM_WEAVER_WASM_BENCH_THREADING_SIZES_MIB (default 128)
  • ROM_WEAVER_WASM_BENCH_THREADING_SEQUENTIAL_THREADS (default 1)
  • ROM_WEAVER_WASM_BENCH_THREADING_PARALLEL_THREADS (default 4)
  • ROM_WEAVER_WASM_BENCH_THREADING_STRIDE_MIB (default 2)

The browser WASM runtime reference describes the worker and OPFS APIs these suites measure.