From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Mon, 24 Oct 2011 15:59:31 GMT
Subject: Re: [PATCH] read-cache.c: fix index memory allocation
Message-ID: <4EA58B63.8040800@lsrfire.ath.cx>
In-Reply-To: <7vipne50lz.fsf@alter.siamese.dyndns.org>

Am 24.10.2011 09:07, schrieb Junio C Hamano:
> Thanks.
> 
> This approach may be the most appropriate for the maintenance track, but
> for the purpose of going forward, I wonder if we really want to keep the
> "estimate and allocate a large pool, and carve out individual pieces".
> 
> This bulk-allocate dates back to the days when we didn't have ondisk vs
> incore representation differences, IIRC, and as the result we deliberately
> leak cache entries whenever an entry in the index is replaced with a new
> one. Does the overhead to allocate individually really kill us that much
> for say a tree with 30k files in it?

Probably not; unpack_trees() does that already.  (It calls
create_ce_entry() via unpack_nondirectories() via unpack_callback() via
traverse_trees()).

René