On Mon, Dec 17, 2007 at 12:29:20PM +0000, Simon Marlow wrote:
David Roundy wrote:
I am pleased to announce the availability of the second prerelease of darcs two, darcs 2.0.0pre2.
Thanks!
Continuing my performance tests, I tried unpulling and re-pulling a bunch of patches in a GHC tree. I'm unpulling about 400 patches using --from-tag, and then pulling them again from a local repo. Summary: darcs2 is about 10x slower than darcs1 on unpull, and on pull it is 100x slower in user time but only 20x slower in elapsed time.
I'm not seeing this behavior right now, but am unsure whether it's because of something in my testing, or if I've improved something. I definitely fixed a problem in the no-patches-to-pull case, where we were unnecessarily reading the entire repository because of inadequate laziness. Another possibility is that the problem is one that shows up because of the way the repositories were generated. Incidentally, I *think* that with the latest convert, optimize should be a noop, and if it's not, I'd be interested to hear (but haven't gotten around to testing...). I suspect that if you perform the same sequence in the reverse direction (unpull and repull, but running the commands in the other repository), then you'll see much better performance. My suspicion is that the trouble is that optimize only optimizes for changes since the last tag, so by unpulling this many patches you're going back into "unoptimized" territory. I'm toying with making optimize do a "deep" optimize, but then it'll always be O(N^2), which is a little scary. On the other hand, since we now auto-optimize, making the real thing more expensive shouldn't hurt as much (since it'll not be needed very often). Anyhow, could you retry this test with the above change in methodology, and let me know if (a) the pull is still slow the first time and (b) if it's much faster the second time (after the reverse unpull/pull)? Thanks! David (who is doing darcs hacking in the morning, before the other grownups wake up)