On Mon, Jun 28, 2021 at 07:33:15AM +0200, Patrick Steinhardt wrote: > As expected, performance doesn't change in cases where we do not have a > bitmap available given that the old code path still kicks in. In case we > do have bitmaps, this is kind of a mixed bag: while git-receive-pack(1) > is slower in a "normal" clone of linux.git, it is significantly faster > for a clone with lots of references. The slowness can potentially be > explained by the overhead of loading the bitmap. On the other hand, the > new code is faster as expected in repos which have lots of references > given that we do not have to mark all negative references anymore. I haven't had a chance to look closely at your patches yet, but I like the idea of using an object's presence in the reachability bitmap to perform the connectivity checks. I have wondered how much performance we could eek out by being able to load the .bitmap file without having to read each individual bitmap contained in it. (I believe Peff mentioned this elsewhere, but) I would be be interested in something as simple as an optional .bitmap extension which indicates the list of commits which have a bitmap, and their offset within the bitmap. I'll try this out myself and see if it's worth it. (As an aside, I'll be offline next week, so it may take me a little while to post something to the list).
