Re: [PATCH 0/11] Misc. pull/merge/am improvements

From: Junio C Hamano <junkio@cox.net>
Date: Dec 30, 2006, 19:27 UTC
Message-ID: <7vhcvdjiap.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061228084245.GA18150@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

Show 8 quoted lines

>> I am very tempted to have sliding window mmap() if it helps
>> people on cygwin, for example.
>
> Especially now that NO_MMAP is the default on that platform.
> At this point it may be ready to graduate to next to try and get a
> wider audience.  Since fixing that segfault in pack-objects I can't
> break it.  Of course I couldn't break it before you found that error,
> so take my words with a grain of salt... ;-)

After I fixed a few problems in sp/mmap topic (one was a bug that screwed up OBJ_OFS_DELTA codepath in pack-objects, another was an unrelated bug in send-pack that merging this series revealed), I've tried to redo _all_ merges leading to the tip of 'pu' in git.git history, with small and default mmap window sizes on my primary machine.

With the default setting, the whole experiment to redo 1561 merges took this much:

193.54user 131.17system 5:23.48elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+35700235minor)pagefaults 0swaps

While with smaller window size i.e. with

        [core]
                packedgitwindowsize = 20
                packedgitlimit = 4194304

the numbers are almost the same:

195.90user 134.40system 5:29.14elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+35862520minor)pagefaults 0swaps

A more important thing is that the merge results exactly match what I get without sp/mmap (i.e. 'next'). Interestingly, with either configurations, sp/mmap is slightly faster than 'next' but I haven't done repeated tests so it may not be statistically significant.

This is by no means a proof of correctness, but is a good way to gain more confidence in the code.