Re: [PATCH 00/32] Split index mode for very large indexes

From: Richard Hansen <rhansen@bbn.com>
Date: Apr 30, 2014, 20:48 UTC
Message-ID: <53616185.9000208@bbn.com>
In-Reply-To: <1398682553-11634-1-git-send-email-pclouds@gmail.com>

On 2014-04-28 06:55, Nguyễn Thái Ngọc Duy wrote:

Show 6 quoted lines

> 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.

I played around with these changes a bit and have some questions:

  * These changes should only affect performance when the index is
    updated, right?  In other words, if I do "git status; git status"
    the second "git status" shouldn't update the index and therefore
    shouldn't have a noticeable performance improvement relative to Git
    without these patches.  Right?

  * Do you have any before/after benchmark results you can share?

  * Are there any benchmark scripts I can use to test it out in my own
    repositories?

  * Is there a debug utility I can use to examine the contents of the
    index and sharedindex.* files in a more human-readable way?

I'm asking because in my (very basic) tests I noticed that with the following command:

    git status; time git status

the second "git status" had an unexpected ~20% performance improvement in my repo relative to a build without your patches. The second "git status" in the following command also had about a ~20% performance improvement:

    git status; touch file-in-index; time git status

So it seems like the patches did improve performance somewhat, but in ways I wasn't expecting. (I'm not entirely certain my benchmark method is sound.)

Thanks, Richard