Każdy pomiar to ta sama operacja na tych samych danych w trzech systemach, mediana z pięciu prób (duże binaria: z trzech). Wszystko lokalnie, żeby nie mierzyć sieci: TouchQuill bez serwera, Git jako repo lokalne, Perforce na żywym p4d Helix Core 2026.1 z workspace. Sprzęt: AMD Strix Halo, dysk NVMe, Linux 6.18. Skrypt pomiarowy jest w repo — możesz powtórzyć wyniki u siebie.
Słupki pokazują proporcje w obrębie wiersza, liczby to czas w milisekundach.
Na binariach 200 MB słupek Gita wychodzi poza skalę — kompresja zlib i próby delty duszą Git na treści binarnej, podczas gdy CAS TouchQuill jedynie hashuje strumień (BLAKE3 ≈ 900 MB/s). Perforce nie hashuje treści (numery rewizji), stąd bywa szybszy na pojedynczym pliku — kosztem gwarancji integralności, które daje content-addressing.
200 assetów po 2 MB (razem 400 MB), zmiana jednego pliku — czyli najzwyklejszy gest artysty w ciągu dnia. W tym scenariuszu TouchQuill jest szybszy i od Gita, i od Perforce.
| Operacja | TouchQuill | Git | Perforce |
|---|---|---|---|
| status po zmianie 1 pliku | 4 ms | 7 ms | — |
| commit przyrostowy | 8 ms | 43 ms | 42 ms |
Sekret: indeks worktree z cache mtime (bez re-hashowania niezmienionej treści) + hierarchiczne drzewo (niezmienione pod-katalogi współdzielą hash) sprawiają, że praca skaluje się z liczbą zmian, nie z rozmiarem repo.
Commit pojedynczej zmiany w rosnącym drzewie. TouchQuill z indeksem + hierarchią + fsmonitorem trzyma płaską charakterystykę tam, gdzie to się liczy.
| Rozmiar drzewa | TouchQuill | Git | Perforce | |||
|---|---|---|---|---|---|---|
| status | commit | status | commit | status | commit | |
| 1 000 plików | 8 ms | ~10 ms | 4 ms | 9 ms | 59 ms | 11 ms |
| 5 000 plików | 21 ms* | 34 ms* | 6 ms | 14 ms | 152 ms | 9 ms |
| 400 MB assetów (200 plików) | 4 ms | 8 ms | 7 ms | 43 ms | 456 ms | 42 ms |
* z fsmonitorem. Na tysiącach płytkich, drobnych plików tekstowych Git nadal wygrywa — pozostały koszt to serializacja tekstowego indeksu (O(drzewa)), a nie skan. To nie jest profil, do którego zaprojektowano TouchQuill.
Demon nasłuchuje zmian w systemie plików (inotify / FSEvents / ReadDirectoryChangesW), więc status i commit nie obchodzą całego drzewa. Cross-platform — zweryfikowany na Linux i Windows.
| Operacja | bez fsmonitor | z fsmonitor |
|---|---|---|
| commit przyrostowy, 5000 płytkich plików | 60 ms | 40 ms |
| status, 5000 plików | 28 ms | 21 ms |
| commit, głębokie drzewo | 19 ms | 15 ms |
Wydajność to jedno, ale wybór VCS do gry to głównie decyzja o modelu pracy. Poniżej zestawienie funkcji z ośmioma systemami używanymi w gamedev — od Gita po świeżo otwarty przez Epic Lore. Dane wg publicznych materiałów producentów (lipiec 2026).
| Cecha | TouchQuill | Git | Perforce | SVN | Unity VCS | Ark | Diversion | Lore |
|---|---|---|---|---|---|---|---|---|
| Model | Lokalny + serwer | Rozproszony | Scentralizowany | Scentralizowany | Hybrydowy | Serwer + klient | Chmura (SaaS) | Centralny + offline |
| Duże binaria natywnie (bez LFS) | ✓ | ✗ | ✓ | ~ | ✓ | ✓ | ✓ | ✓ |
| Locki plików z kolejką | ✓ | ✗ | ~ | ~ | ✓ | ✓ | ~ | — |
| Konflikt jako dane (nie blokuje) | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Adresowanie treścią (hash) | ✓ | ✓ | ✗ | ✗ | ✗ | — | — | ~ |
| Historia symboli / Lens | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Praca offline (commit / branch) | ✓ | ✓ | ~ | ✗ | ✓ | ✓ | ~ | ✓ |
| Self-host / on-premise | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| Open source | ~ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ |
| Model kosztowy | W przygotowaniu | Darmowy | Komercyjny (per‑seat) | Darmowy | Freemium | Freemium (indie gratis) | SaaS (subskrypcja) | Darmowy (MIT) |
Nie udajemy, że jesteśmy wszędzie najlepsi. Lore (Epic) i Ark to mocni, świeży gracze o zbliżonej filozofii — Lore jest w dodatku open source na MIT, a Ark ma dokładnie taki sam mechanizm locka z kolejką jak my. Dwie rzeczy, których nie ma nigdzie indziej, to konflikt trzymany jako dane (integracja nigdy nie staje) oraz Lens — historia symbolu przeżywająca zmiany nazw plików i refaktoringi. Perforce i Diversion nadrabiają dojrzałością i ekosystemem; my stawiamy na model pracy.
Na plikach 50–200 MB commit jest kilkanaście razy szybszy niż w Gicie. To scenariusz, dla którego ten system powstał.
Codzienny commit w repo assetów: 8 ms, wobec 43 ms w Gicie i 42 ms w Perforce.
Hash BLAKE3 na każdym obiekcie pozwala wykryć każde przekłamanie danych. Perforce tej gwarancji nie daje.
Na tysiącach drobnych plików tekstowych Git nadal jest szybszy — jego binarny indeks dojrzewał 20 lat. Przyjmujemy to świadomie: to profil typowego projektu software, nie gry.
Reprodukcja: scripts/bench-vs.sh w repozytorium (uruchamia własny p4d, security=0). Wyniki surowe w bench-results.csv.