Re: [PATCH] bitmaps: don't recurse into trees already in the bitmap

> 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. :)