Benefits from a real world switch from CVS to darcs

by Mark Stosberg

Performance: the good and the bad.

When darcs performs better

In my common usage, there is one case where darcs is noticeably faster than CVS: Tagging the repository. With CVS it takes 5 minutes or more to tag a release, as I wait for CVS to update records for the thousands of files in the project.

With darcs, tagging is instant because it's unrelated to the size of the repository.

When darcs performs worse and what I can do about it.

There are some cases when darcs performs noticeably slower. In the most common cases with the most common commands (record, push and pull), performance is fine.

One that is much slower than CVS right now is using darcs diff to see what's changed in a file since the last version.

This is more of annoyance than a real problem. With CVS the equivalent command was nearly instant, with darcs it can take more like 10 seconds -- enough to notice and become impatient. This issue may have been adequately solved for me today through the release of darcs.vim, a Vim text editor plugin which provides darcs integration. It takes a known shortcut which makes the speed instant, not to mention presenting me a nicely formatted diff in my editor! (For those in the Emacs camp, I believe there is an Emacs mode which uses the same technique )

The real problem is that sometimes when there are conflicts, darcs can go into an exponential computation, hogging the processor for hours to compute the correct result. I should add that this is on top of the author's priority list and is currently being worked on over the 2004-2005 winter break. The problem cuts to the core of darcs' design. Since there aren't any other systems designed quite like this, no one really knows how much the performance can be improved, although the author is optimistic. (Or perhaps that should be 'optimizationistic'?)

Since our switch, this hasn't been a problem for us that I recall, although I have seen it happen a number of times in other places. I expect it to occur at some point.

However as a small isolated team, I think we could workaround this fairly quickly. With the design of our patch flows, we should notice the potential conflict before we are pulling a patch into production. After isolating the conflicting patches, we can eliminate one from our system, and create another one that means that same thing, but conflicts a minimal amount.

I still see these performance issues as a notable drawback, but considering all the benefits I presented above, I think they are worthwhile to put up with, especially if they will be addressed soon.