Hi, Eric Kow <[EMAIL PROTECTED]> writes: > Hmm... it sounds like the slowdown is not a 2.1 blocker then; as a user, > I would generally expect darcs check to do something thorough, so maybe > I would be happier that it's just being extra-thorough now :-P and go > enjoy my coffee. the slowdown itself is not a blocker, I'd agree. However, the memory consumption might be more of an issue -- it will currently hold up to 100 patches worth of files in memory. Fixing that is the other part of the changes I have proposed -- about the SlurpDirectory (or SlurpMonad) refactor, which I am not sure how would look like yet and where I think it might be more of a risk than we can afford for 2.1. The general idea would be to keep track, inside SlurpMonad, how much we went "out of sync" with the original Slurpy and allow synchronisation to disk depending on that "out of syncness". It would at the same time improve memory usage *and* speed up check/repair by avoiding the many intermediate flushes that are apparently often unjustified (we just sync every 100 patches now).
> Also, for this particular case, maybe it would be useful to have > darcs check --only-test Well, depending on how timings turn out after we improve check/repair times, I'd probably try to avoid that extra flag and the associated clutter. 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
