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

[Richard Hansen <rhansen@bbn.com>]

On 2014-04-28 06:55, Nguyễn Thái Ngọc Duy wrote:
> 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