Każda liczba to realny czas, który czekasz, aż Twoja zmiana dojdzie do serwera albo zmiana kolegi dojdzie do Ciebie. Ta sama operacja, te same pliki, w TouchQuill, Git, Git LFS i Perforce, na łączach od szybkiego biurowego po wolne komórkowe. Mediana z kilku prób. Benchmarki możesz pobrać i powtórzyć te pomiary u siebie.
Każdy słupek to cały czas, który człowiek czeka: zmiana robi pełną drogę do serwera i z powrotem. Systemy ułożone od najszybszego, więc kolejność zmienia się z wykresu na wykres. Wygrywamy w codziennej pracy, przy wysyłaniu i odbieraniu zmian; pierwsze pełne pobranie to miejsce, gdzie mamy jeszcze do nadrobienia.
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 |
Serwer i klient nie przesyłają surowych bajtów. Trzy mechanizmy, kompresja, transfer deltowy i cache biurowy, sprawiają, że przez łącze przechodzi ułamek tego, co widzi dysk. Wszystkie zmierzone na działającym serwerze przez LAN (TLS włączony).
| Scenariusz | Na dysku / w repo | Na łączu |
|---|---|---|
| Push korpusu kodu (kompresja zstd) | 78 MB | 15 MB (5,2:1) |
| Re-commit pliku 200 MB po zmianie 1 MB (chunking) | 200 MB | ~3 MB |
Kompresja. Kod i pliki tekstowe zstd ściska średnio około pięć razy, więc wysłanie 78 MB kodu po sieci lokalnej zajmuje 1,4 s. Pliki, które są już skompresowane, tekstury, dźwięk, wideo, na kompresji nic nie zyskują, więc idą w całości, bez marnowania czasu na próby ich ściskania.
Wysyłanie samych zmian. Kiedy poprawiasz mały wycinek dużego pliku binarnego, powiedzmy jednej tekstury albo modelu ważącego kilkaset megabajtów, TouchQuill nie wysyła całego pliku od nowa. Rozbija go na kawałki i przez łącze (oraz na dysk) idą tylko te, które naprawdę się zmieniły. W pomiarze: zmiana 1 MB w pliku 200 MB to około 3 MB transferu, nie 200 MB.
Równoległe pobieranie. Duże pobrania lecą ośmioma strumieniami naraz, żeby wykorzystać całą przepustowość. Pierwsze ściągnięcie całego repozytorium, 2,1 GB assetów z Unreala, zajmuje około 19 s po sieci 1 GbE.
Wysłanie zmiany w dużej binarce jest prawie 4× szybsze niż w Gicie i 9× niż w Git LFS (plik 60 MB, po sieci). To scenariusz, dla którego ten system powstał.
Wysłanie zmiany w repo assetów jest szybsze niż w Gicie i Perforce (repo 400 MB, po sieci).
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.