Re: Bitkeeper

[Jacob Gorm Hansen <jacobg@diku.dk>]

Sean Perry wrote:

> Haskell is a bit slower, but the real culprit is design related. The 
> author and crew are working on it. Should be cleared up eventually.

Hmm, the Wiki page about darcs performance looks rather scary:

http://www.scannedinavian.org/DarcsWiki/Performance

And quoting from the "Best Practices" page at

http://www.scannedinavian.org/DarcsWiki/BestPractices :

"Also, very large conflicts and complex conflicts can cause darcs to use 
an exponential amount of CPU power to solve the problem, giving the 
appearance that darcs is "spinning" or "hanging""

 From what I have read about darcs, the problem is the 'theory of 
patches' approach which demands that all patches be loaded into memory 
at once so that the order in which they should be applied can be 
determined via a n*n comparison of the contents of each patch against 
the contents of all other patches. While all this talk of quantum 
operators may sound sexy at first, I am fairly sure it is vastly 
overkill for real-world source-control.

I other words, I would not be too optimistic about darcs having its 
performance issues cleared up in the shorter term. Besides, there is the 
issue of using a tool written in a language that the majority of 
programmers will find hard to understand*.

Jacob

* Not me of course, I was exposed to Miranda at an early age ;-)