Performance compared with Git

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

Content-defined chunking re-hashes the file but stores only changed chunks, adding about 1 MiB. Git compresses and stores the full 101 MiB blob again. File rewrite costs depend on the storage system.

Add and commit a 1 GiB file of incompressible bytes, with 3 runs per tool.

Time scales linearly with file size for both tools. mkit’s time goes to file I/O and BLAKE3 hashing. With only 3 runs, mkit’s standard deviation is large (1.04 s on a 3.52 s mean), but the ranges (2.7–4.7 s vs 35.5–36.0 s) do not overlap.

The file holds incompressible bytes, standing in for video or other compressed media.

mkit divides the file into roughly 1,300 chunks, hashes each with BLAKE3, and syncs writes to disk from a thread pool. Git’s SHA-1 hashing and zlib compression are CPU-bound. Run-to-run variation was lower in this measurement (a 43 ms standard deviation on a 373 ms mean), but shared disk I/O still affects these timings.

main has a committed 100 MiB file; branch v2 appends 1 MiB to it. Measures checking out v2 from main.

In this measurement git is about 14% faster, but mkit’s standard deviation is 166 ms on a 412 ms mean (runs ranged from 261 to 783 ms), so the two overlap and the data does not support a reliable winner. On 2026-09-19 a separate run (mkit commit d7afae5, same container class) measured mkit about 6% faster; the two runs disagree, which is consistent with noise. Restoring a ChunkedBlob writes every chunk to one shared file sequentially, and only each chunk’s read-and-verify step runs in parallel. cargo bench -p mkit-benches --bench restore_chunk_fanout measures that step alone: a 128 MiB restore’s chunk-read phase drops from 115.3 ms to 83.2 ms (about 28%). This row measures the full add, commit, checkout, and git process-spawn round trip end to end.

One 100 MiB file, one commit

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

Git uses slightly less storage in this measurement. zlib does not reduce the incompressible content. mkit stores roughly 1,300 chunk objects, while Git stores one loose blob. Each file occupies whole 4 KiB filesystem blocks, so mkit’s chunk files add more overhead on ext4 than in the previous APFS measurement.

Growth after a 1 MiB change

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

mkit adds about 1.2 MiB: the appended data, one changed boundary chunk, and a new manifest. Git’s loose object store adds the full 101 MiB blob. After git gc, Git’s growth falls to about 1.0 MiB, similar to mkit.

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 new manifest, tree, commit, and packmap node bring the transfer to about 1.5 KiB, compared with about 71 KiB for the changed chunk. Delta encoding applies only to transfers and only when it is smaller than the raw chunk. The receiver verifies each reconstructed object’s hash before storage.

100 files of 10 KiB random bytes each, staged and committed together.

mkit makes each commit crash-durable by default with two full flushes before renaming objects into place, following Git’s core.fsyncMethod=batch design. Git does not fsync loose objects by default.

Run touch on the committed file to change its modification time without changing its contents, then run add to re-hash it.

The changed modification time invalidates both stat caches, so both tools read and hash the full 100 MiB again. Git’s SHA-1 pass takes longer than mkit’s BLAKE3 pass on this CPU.

mkit init vs git init in a fresh directory.

Both commands finish in a few milliseconds, below hyperfine’s roughly 5 ms shell calibration threshold. mkit’s slowest run was about 7 ms across 332 runs. These timings do not support a reliable speed comparison.

mkit status and git status in a clean repository containing the committed 100 MiB file, with a warm stat cache.

Both timings are below hyperfine’s roughly 5 ms shell calibration threshold. Both tools check cached file metadata with one stat call, without reading or hashing file contents.

100 small files, one commit

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

Both repositories use similar storage: the content size plus per-object overhead.