[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |