Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>> 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.
-
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