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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html