Re: [PATCH 00/83] libify apply and use lib in am

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]