Re: [PATCH 0/3] pack-bitmap: boundary-based bitmap traversal

From: Taylor Blau <me@ttaylorr.com>
Date: Apr 25, 2023, 19:01 UTC
Message-ID: <ZEgjiAtK8O0+dbht@nand.local>
In-Reply-To: <f25c6234-83c0-fa49-85f5-9005e312b8a3@github.com>

On Tue, Apr 25, 2023 at 02:06:25PM -0400, Derrick Stolee wrote:

> In other words: this generates something closer to the object set in the
> non-bitmapped object walk. The only difference is that the new bitmapped
> algorithm will see objects that were re-introduced across the boundary
> (say, a blob was reverted to its older mode).

Very well put, thank you.

Show 11 quoted lines

> For my curiosity, and since you already have a test environment set up,
> could you redo the "without bitmaps" case with pack.useSparse true and
> false? When the option was created and defaulted to true, we never
> really explored comparing it to the bitmap case. In fact, I assumed the
> bitmap case was faster in important cases like this (where there is a
> substantial difference in object counts), but your data is surprising me
> that the sparse algorithm is outperforming bitmaps, even with this new
> algorithm.
>
> The main question I'd like to ask is: is pack.useSparse contributing
> in an important way to the performance here?

I don't know enough about pack.useSparse to say with certainty, but trying again on the same repository (which is reasonably well-packed at the moment), they appear about the same:

    $ time git -c pack.useSparse=false rev-list --count --objects master \
      --not --exclude=master --branches
    14

    real	0m0.986s
    user	0m0.599s
    sys	0m0.387s

    $ time git -c pack.useSparse=true rev-list --count --objects master \
      --not --exclude=master --branches
    14

    real	0m0.985s
    user	0m0.600s
    sys	0m0.385s

> I'll go poking into the patches now.

Thanks in advance for your review :-).

Thanks, Taylor