Each number is the real time you wait for your change to reach the server, or for a teammate's change to reach you. Same operation, same files, in TouchQuill, Git, Git LFS and Perforce, tested over connections from a fast office network down to slow mobile. Median of a few runs. You can download the benchmarks and reproduce these numbers yourself.
Every bar is the whole time a person waits: the change makes the full trip to the server and back. Systems are ordered fastest first, so the order changes from chart to chart. We win on the everyday work, sending and receiving changes; the first full download is where we still have ground to make up.
A daemon listens for file changes at the OS level (inotify / FSEvents / ReadDirectoryChangesW), so status and commit skip walking the whole tree. Cross-platform: verified on Linux and Windows.
| Operation | without fsmonitor | with fsmonitor |
|---|---|---|
| incremental commit, 5,000 shallow files | 60 ms | 40 ms |
| status, 5,000 files | 28 ms | 21 ms |
| commit, deep tree | 19 ms | 15 ms |
The server and client don't ship raw bytes. Three mechanisms, compression, delta transfer and an office-side cache, mean a fraction of what the disk sees crosses the wire. All measured against a running server over LAN (TLS on).
| Scenario | On disk / in repo | Over the wire |
|---|---|---|
| Push a code corpus (zstd compression) | 78 MB | 15 MB (5.2:1) |
| Re-commit a 200 MB file after a 1 MB change (chunking) | 200 MB | ~3 MB |
Compression. zstd shrinks code and text files by about five times, so pushing 78 MB of code over the LAN takes 1.4 s. Files that are already compressed, textures, audio, video, gain nothing from it, so they go whole, with no time wasted trying to squeeze them.
Sending only what changed. When you tweak a small part of a large binary file, say one texture or a model weighing a few hundred megabytes, TouchQuill doesn't re-send the whole file. It splits the file into chunks, and only the ones that actually changed travel over the wire (and land on disk). Measured: changing 1 MB inside a 200 MB file is about 3 MB of transfer, not 200 MB.
Parallel downloads. Large downloads run over eight streams at once to use the full bandwidth. The first pull of a whole repository, 2.1 GB of Unreal assets, takes about 19 s over 1 GbE.
Sending a change to a large binary is almost 4Γ faster than Git and 9Γ faster than Git LFS (60 MB file, over the network). This is the scenario the system was built for.
Sending a change in an asset repo lands faster than in Git and Perforce (400 MB repo, over the network).
A BLAKE3 hash on every object means any data corruption is detectable. Perforce offers no such guarantee.
On thousands of tiny text files Git is still faster: its binary index has had twenty years to mature. We accept that: it's the profile of a typical software project, not a game.