ewah: make bitmap growth less aggressive
authorJeff King <peff@peff.net>
Tue, 8 Dec 2020 22:03:42 +0000 (17:03 -0500)
committerJunio C Hamano <gitster@pobox.com>
Tue, 8 Dec 2020 22:48:16 +0000 (14:48 -0800)
commit2e2d141afdaa2b086ac5d4228de0dd0003eb69ff
tree92e871c039a5ea83244b6ef38b8a3e04c231f1bc
parentd574bf43e806e0d4d6cda7c2f5d016a87843078f
ewah: make bitmap growth less aggressive

If you ask to set a bit in the Nth word and we haven't yet allocated
that many slots in our array, we'll increase the bitmap size to 2*N.
This means we might frequently end up with bitmaps that are twice the
necessary size (as soon as you ask for the biggest bit, we'll size up to
twice that).

But if we just allocate as many words as were asked for, we may not grow
fast enough. The worst case there is setting bit 0, then 1, etc. Each
time we grow we'd just extend by one more word, giving us linear
reallocations (and quadratic memory copies).

A middle ground is relying on alloc_nr(), which causes us to grow by a
factor of roughly 3/2 instead of 2. That's less aggressive than
doubling, and it may help avoid fragmenting memory. (If we start with N,
then grow twice, our total is N*(3/2)^2 = 9N/4. After growing twice,
that array of size 9N/4 can fit into the space vacated by the original
array and first growth, N+3N/2 = 10N/4 > 9N/4, leading to less
fragmentation in memory).

Our worst case is still 3/2N wasted bits (you set bit N-1, then setting
bit N causes us to grow by 3/2), but our average should be much better.

This isn't usually that big a deal, but it will matter as we shift the
reachability bitmap generation code to store more bitmaps in memory.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ewah/bitmap.c