git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / 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

  List information: http://vger.kernel.org/majordomo-info.html

* 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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).