[darcs-devel] announcing darcs 2.0.0pre1, the first prerelease for darcs 2

David Roundy droundy at darcs.net
Thu Dec 13 17:18:09 UTC 2007


On Wed, Dec 12, 2007 at 01:45:13PM +0000, Simon Marlow wrote:
> "darcs changes" seems to have a big performance regression:
> 
> $ time darcs2 changes --last=10 >/dev/null
> 
> I killed it after 3 minutes of CPU time and the process had grown to 1.4Gb. 
>   darcs1 does this in 0.05 seconds using 2Mb.  Perhaps the repository is 
> corrupted somehow?

Okay, it turns out that it was indeed bad strictness causing the trouble.
For some reason, I had made the PatchInfoAnd data type strict in both its
components, which meant that every time we read a patch ID, we also needed
to parse the patch itself.  Very foolish.  There may be some further
regressions (I'm still running an optimize with profiling enabled.  But
darcs changes --last 10 (with profiling running) now takes me just a bit
over a minute, and not too much memory (I don't quite recall).

It'll be a while before the patch shows up in the main repository (tests
have to run), but when it does, I think it'll fix the worst of the
performance regressions.  I'm shocked how this managed to not be absolutely
devastating on the darcs repository itself.  I guess it's not as big as it
feels.

I think I should do more (sooner) to take advantage of the increased
atomicity of hashed repositories, in particular in allowing darcs to be
far more reponsive to ^C (which is the only way to get profiling
information out of a job other than letting it run to completion).
-- 
David Roundy
Department of Physics
Oregon State University


More information about the darcs-devel mailing list