Each measurement runs the same operation on the same data in all three systems, median of five runs (large binaries: three). Everything is local, so we're not measuring the network: TouchQuill without a server, Git as a local repo, Perforce against a live p4d Helix Core 2026.1 with a workspace. Hardware: AMD Strix Halo, NVMe drive, Linux 6.18. The measurement script is in the repo, so you can reproduce these numbers yourself.
Bars show proportions within each row; the numbers are milliseconds.
On the 200 MB binary Git's bar runs off the row's scale — zlib compression and delta attempts choke Git on binary content, while TouchQuill's CAS merely hashes the stream (BLAKE3 ≈ 900 MB/s). Perforce doesn't hash content at all (revision numbers), which is why it can be faster on a single file — at the cost of the integrity guarantees content-addressing provides.
200 assets of 2 MB each (400 MB total), one file changed — the most ordinary thing an artist does all day. In this scenario TouchQuill beats both incumbents.
| Operation | TouchQuill | Git | Perforce |
|---|---|---|---|
| status after changing 1 file | 4 ms | 7 ms | — |
| incremental commit | 8 ms | 43 ms | 42 ms |
The trick: a worktree index with an mtime cache (unchanged content is never re-hashed) plus a hierarchical tree (unchanged subdirectories share their hash) make the work scale with the number of changes rather than the size of the repo.
Committing a single change in a growing tree. With the index, the hierarchy and fsmonitor, TouchQuill keeps a flat profile where it matters.
| Tree size | TouchQuill | Git | Perforce | |||
|---|---|---|---|---|---|---|
| status | commit | status | commit | status | commit | |
| 1,000 files | 8 ms | ~10 ms | 4 ms | 9 ms | 59 ms | 11 ms |
| 5,000 files | 21 ms* | 34 ms* | 6 ms | 14 ms | 152 ms | 9 ms |
| 400 MB of assets (200 files) | 4 ms | 8 ms | 7 ms | 43 ms | 456 ms | 42 ms |
* with fsmonitor. "commit" means an incremental commit (one change). On thousands of small text files Git is still fastest — its binary index has had twenty years to mature; that's the profile of a typical software project, not a game. Perforce has a cheap submit (it doesn't hash content), but its status is a full reconcile against the server — nearly half a second on an asset repo.
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 |
Performance is one thing, but choosing a VCS for a game is mostly a decision about your working model. Here's a feature comparison against eight systems used in game dev — from Git to Epic's freshly open-sourced Lore. Data based on each vendor's public materials (July 2026).
| Feature | TouchQuill | Git | Perforce | SVN | Unity VCS | Ark | Diversion | Lore |
|---|---|---|---|---|---|---|---|---|
| Model | Local + server | Distributed | Centralized | Centralized | Hybrid | Server + client | Cloud (SaaS) | Central + offline |
| Large binaries natively (no LFS) | ✓ | ✗ | ✓ | ~ | ✓ | ✓ | ✓ | ✓ |
| File locks with a queue | ✓ | ✗ | ~ | ~ | ✓ | ✓ | ~ | — |
| Conflict as data (never blocks) | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Content-addressed (hashing) | ✓ | ✓ | ✗ | ✗ | ✗ | — | — | ~ |
| Symbol history / Lens | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Offline work (commit / branch) | ✓ | ✓ | ~ | ✗ | ✓ | ✓ | ~ | ✓ |
| Self-host / on-premise | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| Open source | ~ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ |
| Pricing | TBD | Free | Commercial (per‑seat) | Free | Freemium | Freemium (free for indies) | SaaS (subscription) | Free (MIT) |
We're not pretending to win everywhere. Lore (Epic) and Ark are strong, recent players with a similar philosophy — Lore is even MIT-licensed open source, and Ark ships the exact same queue-based locking we do. The two things you won't find anywhere else are a conflict kept as data (integration never stalls) and Lens — symbol history that survives file renames and refactors. Perforce and Diversion win on maturity and ecosystem; we're betting on the working model.
Committing 50–200 MB files is over ten times faster than in Git. This is the scenario the system was built for.
The everyday commit in an asset repo: 8 ms, against 43 ms in Git and 42 ms in Perforce.
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.
Reproduce it: scripts/bench-vs.sh in the repository (spins up its own p4d, security=0). Raw results in bench-results.csv.