[darcs-devel] Darcs performance and stability

Samuel A. Falvo II sam.falvo at gmail.com
Mon Jun 11 21:04:29 PDT 2007


On 6/11/07, Jason Dagit <dagit at codersbase.com> wrote:
> So the CPU was being consumed but no ram?  Is it possible darcs was
> waiting on another process that was hung like ssh?  (If the processor
> was going at 100% or you were doing everything on the same file system
> this wouldn't be the case.)  Do you know which version of darcs you're
> using?

1.0.9rc2 at the time, when trying to merge patches from two local
branches.  That is:

Given a shell script:

#!/bin/bash
#
# mknchdir <path>
mkdir -p $1
pushd $1

I did this:

$ cd foo
$ # hack hach hack
$ darcs init; darcs add --recursive *
$ # hack a little....
$ popd
$ darcs get foo bar
$ darcs get foo baz
$ cd bar
$ # hack on bar for about two weeks.
$ cd ../baz
$ # hack on baz for about two weeks.
$ cd ..
$ darcs get bar combined
$ cd combined
$ darcs pull ../baz
ZZZZZzzzzzzzzzzzz..........

As you can see, nothing really exotic.  And, I knew that I'd have to
resolve conflicts in the process.  But, for whatever reason, darcs
decided to solve the halting problem.  No remote repositories were
harmed in the making of the e-mail.

> I had a conversation with David once where he made a very good point
> about the speed of darcs on repos like the linux kernel.  How many
> projects out there are the size of the linux kernel in terms of code
> base, history and number of contributors?  I think the current goal is

At my place of employment, our project is about 4x the size of Linux's
repository, all total.  :(  It took git a solid 35 minutes just to
_import_ the project into the local repo.  It was pretty zippy once
imported though.

I mentioned that it was stable because it has to be operator error.
But, after reading the documentation for hours, I still must not have
grokked something because it behaved differently from my expectations.
 This isn't necessarily a bug.  After all, it's in use by the Linux
kernel developers.  And with 4 merges a day, I would _expect_ that
"git push" and "git pull" do work, somehow.

Still, this raises something very, very important.  Darcs has a
_vastly_ superior user interface.  And that, alone, is why I want
darcs to "win" over git.  :)  It has that distinct "It Just
Works"-ness to it.  Usually.

> to get darcs working flawlessly on the common case of repositories and
> then maybe we can scale it on up to handle linux sized code bases.

True, and again, I can deal with this through other means.  I always
have been.  Indeed, the fact that darcs doesn't grok Unix file
attributes of any kind means I can't use it for the all-encompassing
tool, which is a real pity for me.  But, I've adjusted.

Provided it doesn't hang itself in the process, that is.  :D

> Bug reports and feed back are very valuable. It sounds like you're a
> programmer.  Assuming you don't already program in Haskell, I would

I have Haskell experience, but I'm far from expert.  I am using it on
my next generation of CUT though.  It's the project that taught me the
language as well as how to (more or less) efficiently deal with
strings.

> estimate it takes 1-2 years of studying Haskell in one's spare time to
> become proficient enough to hack on darcs.  Even faster if you have
> lots of spare time.  New developers are always welcome.

My problem is time, not experience.  I understand Haskell, though I
don't understand Darcs' source structure, or the algorithms used.  Any
"big project" needs, minimum, 6 months of acquaintance time, I've
found.  Still, what would extra developers bring to the table?

What's needed most, I think, is the ability to reproduce bugs.  It's
the intermittent bug that kills.  :)

-- 
Samuel A. Falvo II


More information about the darcs-devel mailing list