On Sun, Apr 24, 2016 at 8:33 PM, Christian Couder <christian.couder@xxxxxxxxx> wrote: > Sorry if this patch series is a bit long. I can split it into two or > more series if it is prefered. I suspect you deliberately made the series long just to show off how good new git-rebase is ;-) > Performance numbers: > > - A few days ago Ævar did a huge many-hundred commit rebase on the > kernel with untracked cache. > > command: git rebase --onto 1993b17 52bef0c 29dde7c > > Vanilla "next" without split index: 1m54.953s > Vanilla "next" with split index: 1m22.476s > This series on top of "next" without split index: 1m12.034s > This series on top of "next" with split index: 0m15.678s I was a bit puzzled why split-index helped so much. It shouldn't have in my opinion unless you paired it with index-helper, to cut down both read and write time. So I ran some tests. Long story short, I think we can achieve this gain (and a little more) even without split-index. I ran my measurement patch [1] with and without your series used this series as rebase material. Without the series, the picture is not so surprising. We run git-apply 80+ times, each consists of this sequence read index write index (cache tree updates only) read index again optionally initialize name hash (when new entries are added, I guess) read packed-refs write index With this series, we run a single git-apply which does read index (and sharedindex too if in split-index mode) initialize name hash write index 80+ times This explains why I guessed it wrong: when you write only, not read back, of course index-helper is not required. And with split-index you only write as many entries as you touch (which is usually a small number compared to worktree's size), so writing 80+ times with split-index is a lot faster than write 80+ times with whole index. But why write so many times when nobody reads it? We only need to write before git-apply exits, either after successfully applying the whole series, or after it stops at conflicts, and maybe even at die() and SIGINT. Yes if git-apply segfaults, then the index update is lost, but in such a case, it's usually a good idea to restart fresh anyway. When you only write index once (or twice) it won't matter if split-index is used. [1] http://article.gmane.org/gmane.comp.version-control.git/292001 -- Duy -- 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