From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 23 Aug 2016 22:26:13 GMT
Subject: Re: [PATCH 6/7] delta_base_cache: use hashmap.h
Message-ID: <xmqqoa4jt94q.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160822220007.lh3wzv6orlupfjmr@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> So while the value for that case _isn't_ as good as the
> optimal one measured above (which was 2048 entries), given
> the bouncing I'm hesitant to suggest that 2048 is any kind
> of optimum (not even for linux.git, let alone as a general
> rule). The generic hashmap has the appeal that it drops the
> number of tweakable numbers by one, which means we can focus
> on tuning other elements, like the LRU strategy or the
> core.deltaBaseCacheLimit setting.
>
> And indeed, if we bump the cache limit to 1G (which is
> probably silly for general use, but maybe something people
> with big workstations would want to do), the linux.git log-S
> time drops to 3m32s. That's something you really _can't_ do
> easily with the static hash table, because the number of
> entries needs to grow in proportion to the memory limit (so
> 2048 is almost certainly not going to be the right value
> there).
>
> This patch takes that direction, and drops the static hash
> table entirely in favor of using the hashmap.h API.

Sounds very sensible.