| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Bitkeeper
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 ;-)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home