|
Here we will explore how to increase the speed when checking out a repository using the Linux kernel as popular and well-known example. We will see how fast we can go with git itself and then transition to an early implementation provided by gitoxide while trying to make it as comparable as possible while pointing out the differences.
Tl;dr
On tmpfs, one can now checkout v5.16 of the Linux kernel in ~874ms, which equals more than 85k files/s and 1.2GB/s on a machine with 8hpc/2ec on MacOS 12. gix, the plumbing binary of gitoxide, is 1.8 times faster than git with multi-threaded checkout (even though it's not a perfect apples to apples comparison, see Caveats).
Here is the results measured on a 10 core MacBook…
…with 10 cores…
| wallclock |
files |
throughput |
speedup |
efficiency¹ |
|---|
| git |
1.584s |
49.9k/s |
689MB/s |
1x |
40% |
| gix |
874ms |
85.8k/s |
1.3GB/s |
1.81x |
60% |
…and with a single core… .
| wallclock |
files |
throughput |
speedup |
|---|
| git |
5.084s |
14.6k/s |
214.8MB/s |
1x |
| gix |
4.447s |
16.7k/s |
246MB/s |
1.14x |
Take a look below the fold at the very bottom of the document for another table showing results of checking out on a real file system - gix will do that in ~3.3s and git takes 4.6s. There you also find instructions for how to repeat the test on your system.
Bonus: gix on even more powerful CPUs with 10-core limit
| CPU |
wallclock |
files |
throughput |
|---|
| Intel Xeon Gold 6248 CPU @ 2.50GHz |
548.3ms |
135.6k/s |
2.0GB/s |
| AMD EPYC 7643 48-Core Processor |
402.5ms |
184.8k/s |
2.7GB/s |
For details of the runs, see this comment and this one.
What is 'efficiency¹'?
This value measures the effective scaling and the difference between 100% and the actual value would be waste.
If a single core finishes the task in X time, then N cores should finish in X/N time if they would scale perfectly.
The percentage is calculated using <files/s measured for N> / (<files/s measured for 1> * N).
N is 8.5 (8HP cores + (2E cores * 0.25).
What is a 'checkout'?
git will create an index from a tree if none is present and use the in-memory index to checkout files. From what I can see, it will always check for existence of the file prior to writing it using lstat as it uses this as part of its collision detection mechanism along with change detection. Once a file is written, another lstat call is issued to update that information in the in-memory index. Finally, the in-memory index is written back to disk.
git pays great attention to not allow symlinks in the path of a file that is being checked out nor will it write through a symlink. Additionally it will track collisions on file systems that are case-sensitive or have other folding rules for that matter.
Caveats
gitoxide in its current very specialized implementation named checkout-exclusive requires the target directory is empty and fully under its control, hence the -exclusive suffix, a situation that would be present for initial clones. It needs an index to be present and will not write the updated in-memory index back to disk, thus it does less work than git. It does, however, pay the same attention to correctness as git does, and detects collisions while avoiding to write through symlinks.
Creating an index from the tree at v5.16 of the linux kernel appears to take 200ms (time git read-tree HEAD), and is something that typically doesn't have to be done as an existing index is used. It's something we do in our tests to force git to actually perform the full checkout. Writing the index back with a single thread seems to take 40ms using touch a && time git add a with a single thread. If gitoxide were to perform all these operations (none of which are implemented) equally well one would have to add ~240ms to the results. Having marked a sub-second checkout time for the linux kernel I will be hard pressed to assure to stay sub-second even when these operations are done.
Special Thanks
- @joshtriplett got this article started by suggesting to run it on TMPFS to minimize IO cost, and pushed for the
sub-second headline you see here now. Previously I planned to get to less than 2 seconds only. Additionally the git invocation with hyperfine was provided by him and was used just like that. Oh, and he is the reason you can read those tables, there were much more complicated before. Thank you!
- @sharkdp as the author of
hyperfine, an indispensable tool to run benchmarks and comparisons, and sometimes it can help reproduce race conditions, too.
- @pmmccorm for contributing additional results on very powerful machines, setting a new performance record right away.
Reproduction and Measurements |
