Re: [PATCH 4/3] untracked-cache: use FLEX_ALLOC to create internal structs

From: Jeff King <peff@peff.net>
Date: Apr 19, 2019, 19:43 UTC
Message-ID: <20190419194329.GA28277@sigill.intra.peff.net>
In-Reply-To: <CACsJy8BHwM5dUqa-FOjr3smxJT6kW4z7vLUJvsHuhjxwUjvkBw@mail.gmail.com>

On Fri, Apr 19, 2019 at 04:18:25PM +0700, Duy Nguyen wrote:

Show 11 quoted lines

> > I also wondered if we could just accept the cost of calloc() here and
> > use FLEX_ALLOC to simplify things. That resulted in the patch below, but
> > I didn't include it with the initial 3, because I think it's too
> > subtle/gross for my tastes.
> 
> It's probably ok. If I remember correctly, reading UNTR extension (on
> a huge repo) took the longest time after Ben added support for reading
> the index with multiple threads. So performance is a concern, but I
> don't think calloc() would be the problem. malloc() itself without the
> memory pool could probably slow down more when we have lots and lots
> of directories.

I think if we do the FLEX_ALLOC_COPY() thing I mentioned that it would probably _not_ use calloc() there, since we'd know we were copying in the content from elsewhere. So that concern would go away either way. :)

(But I'm still skeptical that FLEX_ALLOC_COPY() is worth it unless we can find at least one other caller).

-Peff