Jeff King <peff@xxxxxxxx> writes:
> +static inline int *slab_at(struct commit_slab *s, const struct commit *c)
> +{
> + if (s->alloc <= c->index) {
> + int new_alloc = alloc_nr(s->alloc);
> + if (new_alloc <= c->index)
> + new_alloc = c->index + 1;
> +
> + s->buf = xrealloc(s->buf, new_alloc * sizeof(*s->buf));
> + memset(s->buf + s->alloc, 0, new_alloc - s->alloc);
> + s->alloc = new_alloc;
> + }
> + return s->buf + c->index;
> +}
This will hurt more as the number of objects we deal with grows (our
ALLOC_GROW() shares the same).
I wonder if it might be a good idea to do
struct commit_slab {
int piece_size;
int piece_count;
struct commit_slab_piece {
int *buf;
} *piece;
};
and then make the look-up logic like this:
int nth_piece, nth_slot;
nth_piece = c->index / s->piece_size;
nth_slot = c->index % s->piece_size;
if (s->piece_count <= nth_piece) {
/* xrealloc s->piece to grow, update s->piece_count */
}
if (!s->piece[nth_piece]) {
/* xcalloc s->piece[nth_piece] to allocate */
}
return s->piece[nth_piece]->buf + nth_slot;
Other than that, looks like a good technology demonstration.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html