# Benchmarks

The harness is `crates/oxy-core/tests/bench.rs` (spec §25). It builds a

repository through the library, one commit at a time, then times the

everyday operations against thresholds:

    OXY_BENCH_DIR=~/.cache/oxy-bench \

      cargo test --release -p oxy-core --test bench -- --ignored --nocapture

`OXY_BENCH_FILES` (default 10 000) and `OXY_BENCH_CHANGES` (default

5 000) set the size. The data lands under `OXY_BENCH_DIR`; `/tmp` is often

a RAM disk, which hides the cost of `fsync`, so measure on a real disk.

## 2026-09-28: first run

Machine: 8 cores, x86-64, NVMe (ext4 on LVM), release build, warm cache.

Files are 21 lines each in 100 directories; one change in ten appends a

line to `hot.txt`, the rest rewrite one ordinary file.

| Operation (10 000 files, 5 000 changes) | Time | Threshold | |

|---|---:|---:|---|

| commit: import 10 000 files | 1 031 ms | 60 000 ms | ok |

| commit: one file (mean of 4 999) | 3 761 ms | 250 ms | **over** |

| status: clean working copy (stat crawl) | 2 977 ms | 2 000 ms | **over** |

| status: 10 files modified | 3 062 ms | 2 000 ms | **over** |

| commit: 10 files | 9 089 ms | 500 ms | **over** |

| log: whole bookmark | 408 ms | 2 000 ms | ok |

| blame: hot file (500 lines) | 2 920 ms | 2 000 ms | **over** |

| blame: ordinary file | 2 927 ms | 1 000 ms | **over** |

| checkpoint | 596 ms | 10 000 ms | ok |

| status after checkpoint | 2 873 ms | 2 000 ms | **over** |

| push: everything to an empty remote | 782 ms | 60 000 ms | ok |

| push: up to date | 4 ms | 1 000 ms | ok |

| clone: everything, with checkout | 3 378 ms | 60 000 ms | ok |

| fsck | 7 955 ms | 60 000 ms | ok |

| gc | 9 489 ms | 60 000 ms | ok |

| status after gc | 2 829 ms | 2 000 ms | **over** |

Peak resident memory over the whole run: 1 405 MiB. The run took 5 h 14 min,

almost all of it building the history, because each commit costs as much

as a status.

Smaller runs, same machine:

| Files, changes | Mean commit | Clean status | Blame (hot) | Peak memory |

|---|---:|---:|---:|---:|

| 1 000, 200 | 90 ms | 62 ms | 62 ms | 70 MiB |

| 1 000, 800 | 166 ms | 130 ms | 119 ms | 118 MiB |

| 4 000, 200 | 343 ms | 235 ms | 239 ms | 254 MiB |

| 10 000, 5 000 | 3 761 ms | 2 977 ms | 2 920 ms | 1 405 MiB |

### What it shows

Sync, log, checkpoints and repository maintenance are fine. Everything

that snapshots the working copy (status, commit, blame of the working

copy's base) grows with both the number of files and the length of the

history. Timing the phases of one snapshot at 4 000 files and 300 changes:

| Phase | Time |

|---|---:|

| load the base state (checkpoint plus the changes since) | 75–130 ms |

| materialize every file of the base state | 75 ms |

| walk the working copy against the manifest | 50 ms |

| build the working-copy change | 8 ms |

A clean status should be a stat walk and nothing else. The fix is backlog

item O10: skip loading and materializing when every file's stat matches a

manifest written for the same base, make the base state lazy for the

callers that need it, and cache materialized snapshots per state. The

thresholds above stay as they are until then, so the harness reports the

gap rather than hiding it.

## 2026-09-28: after O10a

`State::maximal` compared every pair of heads, and the benchmark's

bookmark has about 4 500 of them (changes to different files are

independent). It now walks once; commit also stops loading the base state

twice. Same machine and size:

| Operation (10 000 files, 5 000 changes) | Before | After | Threshold | |

|---|---:|---:|---:|---|

| commit: one file (mean of 4 999) | 3 761 ms | 861 ms | 250 ms | **over** |

| status: clean working copy | 2 977 ms | 803 ms | 2 000 ms | ok |

| status: 10 files modified | 3 062 ms | 864 ms | 2 000 ms | ok |

| commit: 10 files | 9 089 ms | 861 ms | 500 ms | **over** |

| log: whole bookmark | 408 ms | 400 ms | 2 000 ms | ok |

| blame: hot file | 2 920 ms | 809 ms | 2 000 ms | ok |

| blame: ordinary file | 2 927 ms | 828 ms | 1 000 ms | ok |

| status after checkpoint | 2 873 ms | 770 ms | 2 000 ms | ok |

| push: everything | 782 ms | 742 ms | 60 000 ms | ok |

| clone: everything | 3 378 ms | 1 664 ms | 60 000 ms | ok |

| fsck | 7 955 ms | 6 872 ms | 60 000 ms | ok |

| gc | 9 489 ms | 9 526 ms | 60 000 ms | ok |

Peak resident memory: 1 145 MiB (was 1 405). The run took 1 h 12 min

(was 5 h 14 min). Commit time no longer grows with history; what remains

grows with the number of files: at 10 000 files a snapshot spends about

320 ms loading the base state, 190 ms materializing it, 130 ms walking the

working copy and 40 ms building the change. That is O10b.

## 2026-09-28: after O10b

Rendering the base state, building file graphs from a checkpoint and

reading the working copy now run on all cores. Measured at 10 000 files

with 60 and 300 changes (commit time no longer depends on the length of

history, so the full 5 000 was not rerun):

| Phase of one snapshot, 10 000 files | After O10a | After O10b |

|---|---:|---:|

| load the base state | 320 ms | 180–280 ms |

| materialize the base state | 190 ms | 75 ms |

| walk and read the working copy | 130 ms | 80 ms |

| build the working-copy change | 40 ms | 40 ms |

| write the manifest | – | 46 ms |

| Operation, 10 000 files | After O10a | After O10b | Threshold |

|---|---:|---:|---:|

| status: clean working copy | 803 ms | 464–581 ms | 2 000 ms |

| commit: one file (mean) | 861 ms | 550–605 ms | 250 ms |

| commit: 10 files | 861 ms | 583–635 ms | 500 ms |

Loading the whole base state is now the largest cost. O10c removes it: a

snapshot should load and render only the files whose stat changed, which

needs checkpoints that can be read per file.