Performance Benchmarks

Last updated: 2026-05-18 Primary benchmark build: 0.4.0 release build, commit f26a103.

Replay Control is designed to run quietly on a Raspberry Pi while still handling large game libraries. The practical result from the 0.4.0 measurements is:

• Normal browsing is fast. Home renders in about 10 ms, game pages in 1-3 ms, and common searches in about 26-31 ms on a Pi 5.
• Idle memory is small after startup settles: roughly 45-61 MB on the measured USB library.
• Light browsing stays modest: about 74-77 MB and about 0.6% of one CPU core when no game is running.
• Heavy artificial load raises memory temporarily, but the service remains responsive and memory drops back afterward.
• Large NFS libraries are slower to scan and search, but the app remains usable while maintenance work continues.

The main 0.4.0 numbers below use USB storage with 23,666 games. A separate NFS section records the larger 102 K+ ROM development library.

Tested Hardware#

Everyday Use#

CPU Use#

CPU is reported as percent of one core. On a Pi 5, 100% means one core is fully busy.

Memory Use#

Memory is the resident set reported by Linux for the replay-control process.

The peak column is Linux’s high-water mark for the process. It does not go down until the process restarts, even after current memory has dropped.

Startup#

On an unchanged USB library, startup verification completed in 1.4 s after the service restart used for the memory test. The app settled into a roughly 45-61 MB idle range once startup work was finished.

First scans and full rebuilds do more work because they must discover files, enrich metadata, queue thumbnails, and, for hash-matched systems, identify ROMs by CRC. Those longer operations are covered in Library Maintenance on NFS.

Page Load Times#

Warm, single-user page requests on Pi 5 with USB storage:

Download Sizes#

The web app’s static files. WASM is served gzip-compressed by the server.

USB Stress Tests#

These numbers come from Apache Bench (ab) issuing 50 requests per endpoint. This is intentionally heavier than normal use; it is a regression and robustness check.

Concurrent Throughput#

Homepage#

The c=1 homepage run included one long outlier, so Req/s is not representative there. The median and P95 are the useful values for that row.

Search#

System and Game Pages#

Mixed Concurrent Test#

Four endpoints were hit at the same time, each with concurrency 5.

Library Maintenance on NFS#

NFS is a harder workload because scans must walk a remote ROM tree and rebuilds may stream large files to recompute CRCs. Current builds keep catalog.sqlite, library.db, and external_metadata.db on the Pi, so normal page rendering is much less tied to NFS latency than library maintenance is.

Earlier NFS library maintenance measurements on a 95,495-ROM development library:

0.4.0 validation on a larger 99,964-ROM NFS library measured the deferred-identity pipeline:

Follow-up validation on a 102,662-ROM NFS library measured a normal manual rescan after identity had already completed:

The key result is responsiveness. The foreground library becomes available before the hash tail finishes, and the app stays usable during the remaining NFS reads.

NFS Large-Library Serving#

Measured on Pi 5 against the 102 K+ ROM NFS development library after deploying the same 0.4.0 release build from commit f26a103.

Warm Page Requests#

NFS Load Test#

Search is much heavier here than on USB because the NFS development library is more than four times larger.

Memory around the same run:

The high-water mark came from artificial broad-search stress on a very large library. It is not a normal browsing footprint, but it is useful regression data: the process stayed running and served every request class through the stress run.

Historical Comparison#

The current 0.4.0 release is dramatically faster than the original unoptimized implementation and remains comfortably within Pi 5 limits for normal use.

Older intermediate 0.4.0 validation runs had slightly faster home stress throughput and a smaller WASM bundle. The final 0.4.0 numbers above are the release baseline because they include the completed library-build, metadata, and startup-scan changes.

Test Methodology#

• CPU: tools/pi-cpu.sh reads /proc/<pid>/stat and reports CPU relative to one core. --browse simulates one user clicking through home, system pages, search, game detail, and manuals every ~2 s.
• Memory: tools/pi-memory.sh reads /proc/<PID>/status: VmRSS (memory in use), VmHWM (peak since process start), and RssAnon.
• Page and asset benchmarks: tools/bench.sh, with Lighthouse skipped for the recorded release runs.
• Stress tests: tools/load-test.sh, which uses Apache Bench (ab) with 50 requests per endpoint.
• All current USB measurements were taken on a freshly restarted Pi 5, USB storage, no game running, default jemalloc configuration.
• ab’s “Failed” column counts response-size variance, not HTTP errors. All requests returned successfully.
• Raw results are stored in tools/bench-results/.