Taylor Blau <me@xxxxxxxxxxxx> writes: > They are useful in GitHub's infrastructure, where we have seen a > dramatic increase in performance when writing ".rev" files[1]. In > particular: > > - an ~80% reduction in the time it takes to serve fetches on a popular > repository, Homebrew/homebrew-core. > > - a ~60% reduction in the peak memory usage to serve fetches on that > same repository. > > - a collective savings of ~35% in CPU time across all pack-objects > invocations serving fetches across all repositories in a single > datacenter. > > Reverse indexes are also beneficial to end-users as well as forges. For > example, the time it takes to generate a pack containing the objects for > the 10 most recent commits in linux.git (representing a typical push) is > significantly faster when on-disk reverse indexes are available: > ... > In the more than two years since e37d0b8730 was merged, Git's > implementation of on-disk reverse indexes has been thoroughly tested, > both from users enabling `pack.writeReverseIndexes`, and from GitHub's > deployment of the feature. The latter has been running without incident > for more than two years. What is missing is what extra overhead this adds to "git gc". Does it add 5%? 15%? How big an overhead do we find reasonable? Other than that, it looks like that the series is very well crafted. It was somewhat surprising that we still need to add a few new end-user facing or meant-for-testing knobs for a feature that we claim is well battle tested. It is understandable that we benefit by having knobs to selectively _disable_ a part of the feature now it will be on by default. Will queue. Thanks.
