Instead of using a single slab and keep reallocating it as we find
that we need to deal with commits with larger values of commit-index,
make a slab an array of many slab_pieces. Each access may need
two levels of indirections, but we only need to reallocate the first
level array of pointers when
On Sat, Apr 13, 2013 at 11:04:48PM -0700, Junio C Hamano wrote:
Instead of using a single slab and keep reallocating it as we find
that we need to deal with commits with larger values of commit-index,
make a slab an array of many slab_pieces. Each access may need
two levels of indirections,
Jeff King p...@peff.net writes:
On Sat, Apr 13, 2013 at 11:04:48PM -0700, Junio C Hamano wrote:
Instead of using a single slab and keep reallocating it as we find
that we need to deal with commits with larger values of commit-index,
make a slab an array of many slab_pieces. Each access may
On Sun, Apr 14, 2013 at 11:51:40AM -0700, Junio C Hamano wrote:
I don't know if shrinking the size of the realloc is all that big a
deal. We are doubling, so the allocation cost is already amortized
constant time.
I was more disturbed about copying the actual bytes. One of the
Jeff King p...@peff.net writes:
Yes, but isn't that a constant:
(512*1024-32) / sizeof(struct commit_slab_piece)
Leaving it as such lets the compiler optimize better, and is safe from
anybody changing it at runtime. But I think the answer to my question is
yes, that would be the best
5 matches
Mail list logo
