All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Patrick Steinhardt <ps@pks.im>
Cc: Derrick Stolee <stolee@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] bitmaps: don't recurse into trees already in the bitmap
Date: Fri, 18 Jun 2021 08:59:59 -0400	[thread overview]
Message-ID: <YMyYz6Tavj5l6S8n@coredump.intra.peff.net> (raw)
In-Reply-To: <YMnvCI/jksyn2flD@tanuki>

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

  reply	other threads:[~2021-06-18 13:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14  7:27 [PATCH] bitmaps: don't recurse into trees already in the bitmap Jeff King
2021-06-14 12:05 ` Jeff King
2021-06-15 14:17   ` Derrick Stolee
2021-06-16 12:31     ` Patrick Steinhardt
2021-06-18 12:59       ` Jeff King [this message]
2021-06-18 13:35         ` Patrick Steinhardt
2021-06-18 14:10           ` Jeff King
2021-06-22 10:47           ` Patrick Steinhardt
2021-06-22 19:39             ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YMyYz6Tavj5l6S8n@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.