On Wed, Jun 16, 2021 at 02:31:04PM +0200, Patrick Steinhardt wrote: > > These many-refs scenarios make sense as something that is difficult to > > verify using a single fork of an open-source project, but is common in > > many closed-source projects that do not use forking to reduce the ref > > count per repo. > > Agreed. What I typically do to emulate this is to use some version of > following command to create refs for "$n" commits. > > git log --all --format="tformat:create refs/commit/%h %H" | > shuf | head -n "$n" | git update-ref --stdin > > It's obviously not ideal given that resulting refs are distributed at > random. But combined with a sufficiently large repo, it's still helped > me at times to reproduce adverse performance at times. Yeah, I've done something similar. But I'd caution people into reading too much into performance tests from something like that. What I've found over the years is that traversal and bitmap performance can be somewhat sensitive to tree shape and bitmap placement (which in turn is often influenced by ref placement, if you are using delta islands or the recently added pack.preferBitmapTips). More than once I've spent many head-scratching hours trying to determine why some real-world repo performs better or worse than expected. :) > Anyway, the patch does look good to me and sounds like it may help with > some of the cases where I have observed adverse performance with bitmaps > enabled in the past. Thanks! Thanks for taking a look! -Peff
