[darcs-devel] announcing darcs 2.0.0pre1, the first prerelease for darcs 2
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
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).
Department of Physics
Oregon State University
More information about the darcs-devel