Re: What's cooking in git.git (Oct 2013, #06; Fri, 25)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 28, 2013, 16:41 UTC
Message-ID: <xmqqwqkxfiv4.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAFFjANSnuS6_+uAd43AayojJyK-wj2wMxQ6DBD6JyN=A7xh2_A@mail.gmail.com>

Vicent Martí <tanoku@gmail.com> writes:

Show 9 quoted lines

> On Mon, Oct 28, 2013 at 4:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> jk/pack-bitmap adds khash.h, which from a first glance looks like yet
>>> another hash table implementation. I was just wondering if kb's new
>>> hash tables can cover the need of pack-bitmap.c too so we can remove
>>> khash.h later..
>> ...
> khash on the other hand is capable of storing the position values as
> part of the hash table itself (i.e. `int **buckets`), and saves us
> from thousands of bytes of allocations + indirection.

My "Good thinking ;-)" comment was primarily meant as "somebody needs to at least think about the possibility and consider pros and cons", and you thought about it already ;-).

In short, kb's hash table does not cover the need for pack-bitmap, so we should keep two at least for now, until (and/or unless) either side can be shown (and/or extended) to cover the need for the other one as well.

Thanks.