[darcs-users] is darcs 2.4 supposed to be faster? Re: darcs 2.4 beta 2 release
kowey at darcs.net
Sun Jan 24 09:05:06 UTC 2010
On Sun, Jan 24, 2010 at 00:26:31 -0700, Zooko Wilcox-O'Hearn wrote:
> This text makes it sound as though users who upgrade to darcs 2.4
> from earlier versions of darcs can expect performance improvements,
> Are we supposed to expect performance improvements from this
> release? Perhaps the release announcement could be made more
> specific about what, if any, operations are expected to be faster.
> "Index-based diffing" means nothing to me, except possibly that the
> "darcs whatsnew" and "darcs diff" commands should be effected.
You're right, Zooko. We are working to make sure our message on this is
as clear, accurate and precise a message as possible.
I think the heart of your answer lies in
Namely, I expect these operations to be faster than in darcs 2.3.1:
Furthermore, I think these things will have an impact:
- darcs optimize --pristine [all commands?]
- apply no longer sleeps for 1 second
- darcs get now urges people to upgrade their servers to
hashed [since darcs 2.3.1, getting from old-fashioned repos
is slow because we convert to hashed for safety]
Things confusing the issue are:
- Hashed repos vs old-fashioned?
I think we have to ignore this question for now and just focus on
comparing hashed repos with hashed repos.
- Recent regressions in check/repair.
In between the first two betas, Petr has gained a lot of ground on
the regressions. Not all of it, but it's much more reasonable
- Many variables to account for: NFS? branches/symlinks? global
cache size? size of repos in number of files?
Some obstacles we still face (and which we need help on) are:
- Insufficient grasp of statistics in the Darcs Team (Here's one way
you can help out, darcs-users!)
- Lack of benchmarks for the operations record/unrecord/amend-record/
- Darcs-benchmark buggy on Windows: we need a Windows hacker to swoop
in and fix this. Perhaps it's just another file handle leak? So
it doesn't have to be a Windows guy, necessarily, just somebody who
can help track down this leak and work with Max to see if things are
- No way to compare optimize --pristine repos against the unoptimised
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
More information about the darcs-users