On Fri, Jun 18, 2021 at 03:35:05PM +0200, Patrick Steinhardt wrote: > On Fri, Jun 18, 2021 at 08:59:59AM -0400, Jeff King wrote: > > 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. :) > > I couldn't agree more. I've also had my fair share of weird performance > characteristics in completely unexpected ways. Unfortunately, it has > made me become quite cautious about bitmaps given that they've already > caused their fair share of perfomance regressions. > > But your work here actually encourages me to give it another try soonish > and see what kind of repo shapes make them explode this time. > > Patrick Today I've been experimenting with the connectivity check of git-receive-pack(1) once again to see whether I'm able to get a performance improvement if the git-rev-list(1) command spawned as part of the connectivity check uses `--use-bitmap-index`. Turns out the answer is "no": it has exactly the same performance characteristics when pushing into a bitmapped repository (linux.git) compared to the version not using a bitmap index, except for once case where it performs 70x worse: force-pushing "master~10:master" into a bitmapped repo takes 11s instead of 0.15s with bitmaps enabled. Just leaving this here as a note for anybody (or myself) to pick up at a later point. Patrick
Attachment:
signature.asc
Description: PGP signature
