Re: [PATCH 00/32] Split index mode for very large indexes
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Apr 29, 2014, 01:52 UTC
- Message-ID
- <CACsJy8B7P0Un0__9mS2j81PimPZbz9oTKZHKx8yo_smOMck1qA@mail.gmail.com>
- In-Reply-To
- <CAJo=hJtgijOOMPbFjvTUaENw=hr0YixYmy1UkdqEd=CpLZ5L2A@mail.gmail.com>
On Tue, Apr 29, 2014 at 4:18 AM, Shawn Pearce <spearce@spearce.org> wrote:
Show 20 quoted lines
> On Mon, Apr 28, 2014 at 3:55 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote: >> I hinted about it earlier [1]. It now passes the test suite and with a >> design that I'm happy with (thanks to Junio for a suggestion about the >> rename problem). >> >> From the user point of view, this reduces the writable size of index >> down to the number of updated files. For example my webkit index v4 is >> 14MB. With a fresh split, I only have to update an index of 200KB. >> Every file I touch will add about 80 bytes to that. As long as I don't >> touch every single tracked file in my worktree, I should not pay >> penalty for writing 14MB index file on every operation. > > This is a very welcome type of improvement. > > I am however concerned about the complexity of the format employed. > Why do we need two EWAH bitmaps in the new index? Why isn't this just > a pair of sorted files that are merge-joined at read, with records in > $GIT_DIR/index taking priority over same-named records in > $GIT_DIR/sharedindex.$SHA1? Deletes could be marked with a bit or an > "all zero" metadata record.
With the bitmaps, I know the exact position to replace or delete an entry. Merge sort works, but I would need to walk through all entries in both indexes to compare entry name and stage, a bit costly in my opinion. And if you look at the format description in patch 0017, I store the replaced entries without their names to save a bit more space. "EWAH" is just an implementation detail. A straightforward bitmap should work fine (25kb for 200k entries seem reasonable).
-- Duy