Measured against git

Append 1 MiB to the already-committed 100 MiB file, then add + commit the new version.

mkit wins by ~5.0×: content-defined chunking re-hashes the file but stores only the changed chunks, so the second version costs about a megabyte. git re-compresses and stores the whole 101 MiB blob again.

Same shape at 1 GiB, 3 runs each.

mkit wins by ~3.6×. First ingest scales linearly for both tools; mkit’s wall clock is I/O + BLAKE3.

A single 100 MiB file of incompressible bytes (a stand-in for video or other compressed media).

mkit wins by ~2.8×: the file splits into ~1,600 content-defined chunks, each hashed with BLAKE3 and barrier-synced from a thread pool, while git’s SHA-1 + zlib pass stays CPU-bound. mkit’s flush cost is constant per commit, not per chunk.

one 100 MiB file, one commit

Repository size after the first commit of the 100 MiB file.

Roughly even: incompressible input means zlib buys git nothing, so both stores hold roughly the content plus bookkeeping (the gap is mostly filesystem allocation, not format).

growth after a 1 MiB change

Additional repository bytes after appending 1 MiB to the 100 MiB file and committing the second version.

mkit stores ~1.1 MiB: the appended megabyte, one re-cut boundary chunk, and a fresh manifest. git’s loose store duplicates the whole ~112 MiB blob until git gc repacks it back to ~zero growth, so mkit’s store is incremental by construction while git’s is dense only after a maintenance pass.

Edit 16 bytes in the middle of a 2 MiB FastCDC-chunked file the remote already holds, then push the new commit. Bytes counted on the wire.

The chunk delta is 93 bytes; the rest of the ~1.5 KiB is the new manifest, tree, commit, and packmap node, versus re-sending the whole ~71 KiB re-cut chunk. Delta is a transfer encoding only — it is used only when it beats the raw chunk, and every reconstructed object is re-verified against its hash before storage.

100 files of 10 KiB random bytes each, staged and committed in one shot.

mkit wins by ~1.8× while making every commit crash-durable (git does not fsync loose objects by default). Durability is batched behind two fixed full flushes, then renamed into place — git’s core.fsyncMethod=batch design, on by default.

touch the committed file (mtime changes, bytes don’t) and run add again — a pure re-hash.

Close to a tie, mkit a hair ahead: the changed mtime invalidates both tools’ stat caches, so both re-read and re-hash 100 MiB in well under 200 ms and write nothing new.

mkit init vs git init in a fresh directory.

mkit status / git status in a clean repo holding the committed 100 MiB file, stat cache warm.

A tie. An unchanged file is proven clean by one stat call against the index stat cache — O(stat), no read, no hash, the same trick git plays.

100 small files, one commit

Repository size after committing 100 × 10 KiB of random bytes (1,000 KiB of content).

Effectively a tie — both store roughly the content plus per-object overhead.