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.
> 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
