A little over a month ago, I gave an update on our progress of moving the Windows team to Git in the largest Git repo on the planet.  At the time, I described the scale of the Windows Git repo (over 3.5M files and ~4,000 engineers), the current performance results and set of improvements that were just rolling out that we called “O(modified)”.  The O(modified) improvements significantly improve performance by changing many Git commands to be time proportional to the set of files you’ve changed rather than the set you’ve checked out.

Now, ~5 weeks later, we’ve rolled out the O(modified) changes across the majority of the Windows team and we can report actual results from real daily usage rather than synthetic test results.  This reflects typical developer usage with typical enlistment sizes, real world changes, etc.  It is taken from telemetry that is collected from every engineer for every command they run.

In the table below you’ll see the performance results for 6 common commands.  The first two columns are the 80th and 95th percentile times, in seconds, for GVFS before the O(modified) changes.  Of course, remember Git without the GVFS changes would have been many minutes for many, if not all, of these.  The second two columns are the 80th and 95th percentile times, in seconds, for GVFS after the O(modified) changes rolled out.  So, compare columns 1 -> 3 and 2 -> 4 to compare times.  The final two columns are the % improvements for the 80th and 95th percentiles.  As you can see most 80th percentiles improved by 20-30% and up to 78%.  The 95th percentiles improved by much more – more like 50-60% and up to 90%.  99th percentile would be even better.  In general, one of the effects of the O(modified) changes is to substantially shorten the “tail” or the variability of commands – making them faster and much more consistent.

I always use git status as my barometer of performance.  A lot of commands matter but more than any other, status is one that you don’t expect to wait for.  The O(modified) improvements really shine.  I didn’t show it but the 50th percentile for status is under 3 seconds.  My personal goal is to get the 50th percentile down to 1 second.  I’ll feel super proud if we are able to do that but regardless, the results already are quite amazing.

We’ll keep plugging away at improvements and you can follow the work in our GVFS open source project.  We just recently added automount support so GVFS is automatically started after rebooting – so you don’t have to remember to manually do it before accessing your code.

If you’d like to try out Git on a large code base, create a VSTS account, download GVFS and give it a try!

Brian