[darcs-users] darcs-benchmark

[Petr Rockai]

Eric Kow <kowey at darcs.net> writes:

> Also, hmm, are those regressions I'm seeing?
Some of them yes. For the rest, hard to tell.

> === darcs ===
>
>                 || darcs-2.3.1        | darcs       
> ================++====================+=============
>      get (full) ||        5.0s  11.0M |  4.3s  11.0M
> get (lazy, x10) ||        5.2s   3.0M |  4.7s   3.0M
>        pull 100 ||        4.3s  15.0M |  4.4s  25.0M
>        annotate ||       22.3s 176.0M | 18.0s 176.0M
>          wh x50 ||        1.9s   2.0M |  2.6s   2.0M
>      wh mod x50 ||        7.0s   2.0M |  7.1s   2.0M
It is quite interesting how this came about. However, with such small repos as
darcs and ghc-hashed (in terms of working copy size), this is probably just
fluctuation: the times are from 0.038 to 0.052 seconds per query, nothing you
could perceive in any way in normal usage. It could still make some sense to
run darcs optimize --pristine on the repo.* dirs to see if that influences
these numbers.

>       wh -l x20 ||        3.6s   5.0M | 25.3s  22.0M
This is a known problem (it even has a TODO in the code): it needs a way to
combine two Tree objects: the one from readIndex and a readPlainTree, so that
we can implement look for adds efficiently.

>           check ||       21.9s  95.0M | 55.1s 256.0M
>          repair ||       22.0s  77.0M | 54.1s 264.0M
And this is in part due to filename conversions (hashed-storage uses a
different filename model than darcs). For the rest, the Tree Monad code is not
very optimised I guess, and it also takes a somewhat different approach to the
problem than my old Check/Repair optimisation.

(snip; the ghc results are quite similar)

Yours,
    Petr.