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

From: Derrick Stolee <derrickstolee@github.com>
Date: Apr 25, 2023, 19:52 UTC
Message-ID: <5943de3d-3dad-c600-c6d6-3c10c2851071@github.com>
In-Reply-To: <ZEgikbdP8M2sDMlM@nand.local>

On 4/25/2023 2:57 PM, Taylor Blau wrote:

Show 9 quoted lines

> On Tue, Apr 25, 2023 at 02:30:01PM -0400, Derrick Stolee wrote:
>> It would be interesting if we used the initial commit walk to the
>> boundary as a predictor of whether bitmaps would be good, or if
>> we should use the tree-parsing walk instead.
> 
> I think that this is tough, too. When making a prediction, it would be
> good if we could avoid walking down to the nearest bitmap, since by that
> point, you might as well have used bitmaps (if you found one before
> reaching the root(s) of history).

This isn't quite as cut-and-dry, because walking commits is much faster than walking trees. I agree that we shouldn't walk too far to avoid wasting time, but somehow we'd want to think about the distance between the commits we want to cover and the bitmap(s) we found in their history.

Show 9 quoted lines

>> But perhaps this series gets the bitmap walk "close enough" in
>> the typical case that it's better to use bitmaps in the chance that
>> we have accidentally hit a case where we'd normally need to walk a
>> lot of trees.
> 
> Yeah, that is definitely part of this series's goal. Another framing is,
> for configurations that are using bitmaps everywhere, this should reduce
> the number of cases where using bitmaps is *significantly* slower than
> not.

It's a good opportunity to re-think if we should be using bitmaps in these contexts at all, or if there is a simpler thing to do by disabling them when 'haves' exist. I don't think that's the right thing to do in all cases, but the experiments you've demonstrated here seem to point in that direction.

Thanks, -Stolee