Hi,
as I have promised previously, here are the current numbers from "standard
darcs benchmarks".
=== big-zoo/darcs-repo ===
|| darcs 2.2 | darcs 2.0.2 | darcs 2.1
==========++===============+=================+===============
annotate || 16.4s 64M | 16.2s 63M | 15.5s 62M
check || 17.5s 62M | 26.0s 5M | 24.6s 5M
get full || 11.3s 2M | 13.0s 2M | 11.0s 2M
get lazy || 1.9s 0M | 2.2s 0M | 2.0s 0M
pull 100 || 9.2s 7M | 10.2s 7M | 9.7s 9M
pull 1000 || 81.4s 18M | 86.0s 15M | 92.3s 16M
repair || 17.3s 62M | 178.2s 44M | 27.0s 70M
=== big-zoo/ghc-hashed ===
|| darcs 2.2 | darcs 2.0.2 | darcs 2.1
==========++================+==================+================
check || 164.5s 550M | 129.9s 47M | 126.1s 47M
get full || 35.7s 20M | 43.0s 20M | 37.3s 19M
get lazy || 5.2s 0M | 5.8s 0M | 5.6s 0M
pull 100 || 89.8s 36M | 89.0s 37M | 87.0s 34M
pull 1000 || 224.6s 53M | 257.8s 47M | 257.5s 47M
repair || 164.2s 550M | - - | 307.1s 585M
=== big-zoo/small-repo ===
|| darcs 2.2 | darcs 2.0.2 | darcs 2.1
==========++==============+=================+==============
annotate || 0.0s 0M | 0.1s 0M | 0.1s 0M
check || 0.1s 1M | 0.1s 0M | 0.1s 0M
get full || 0.1s 0M | 0.2s 0M | 0.2s 0M
get lazy || 0.1s 0M | 0.1s 0M | 0.1s 0M
pull 100 || 1.0s 0M | 1.0s 0M | 1.0s 0M
pull 1000 || 1.0s 0M | 1.0s 0M | 1.0s 0M
repair || 0.1s 1M | 0.4s 0M | 0.1s 0M
Across the board, darcs 2.2 is looking pretty OK to me. The obvious regression
is darcs check on ghc-sized repos, where 550M is still quite a lot, probably
indicating a memory bug in my code. I will work on this for 2.2
myself. However, this is still better than repair in 2.1, and is now doing the
same robust variant of the check. You can see memory went down by 35M (not very
good) and time went down by nearly a factor of 2, from 307 seconds to
164. That's good. Interestingly, darcs 2.0.2 screwed up during repair on
ghc-hashed, I had to kill it and therefore it has no number in the table. I
don't know why is that. (I did give it over 24 hours to finish one iteration,
which it did not.)
Get has gotten faster in some cases, big pulls even more so. The annotate one
seems to be best in 2.1 and has slightly regressed in 2.2 to roughly the same
figure as it was in 2.0.2 -- this might be worth looking at.
Please also note that all these numbers come from a system with 4 Xeon cores
and 16G of RAM, with the working directory mounted over NFS. I will be running
the same suite of benchmarks (possibly extending it with more cases and/or
repositories) after each tagging (those were outlined in my previous mail).
Ideas for testcases are very much welcome. The testsuite itself lives at
http://code.haskell.org/darcs/darcs-benchmark -- it's not completely ready for
the prime time, but it should be fairly straightforward to get it running. You
need to run "sh initialise.sh" first. It will crunch for a while, and if it
works out, you should be able to run ./go.hs.
Current ideas:
- whatsnew
- whatsnew --ignore-times
- revert -a
- all of the above with some local modifications
- better annotate test (more, better files to annotate)
There are some more ideas at
http://wiki.darcs.net/index.html/StandardDarcsBenchmarks -- which reminds me,
that this page could make use of some gardening. If anyone was to grab a
current copy of darcs-benchmark and update the wiki accordingly, that would be
great!
Yours,
Petr.
--
Peter Rockai | me()mornfall!net | prockai()redhat!com
http://blog.mornfall.net | http://web.mornfall.net
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton on the subject of C program indentation
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
