[darcs-users] Benchmarking "get"

Max Battcher me at worldmaker.net
Sun Mar 15 08:34:52 UTC 2009

Trent W. Buck wrote:
> Max Battcher <me at worldmaker.net> writes:
>> I seriously believe that most git users are hugely underestimating the
>> speeds of their git operations...
> FWIW, git *is* slower for me because instead of running one darcs
> command, I have to run two or three git commands to achieve the same
> goal.  That means I spend more time typing and reading -- whereas with
> Darcs I have switched away to another window, so I don't notice if it
> takes twenty seconds instead of five seconds.

Git is entirely out of the question for my workflow. The big killer is 
Windows support, and to be honest I don't know how much of the speed 
issues I see are weird port issues and how much is legitimate git 
stupidity, but to do what I do everyday in darcs seems to take twice as 
long on average. But then, maybe I haven't given git a fair shake for 
its considerable learning curve...

I think we need to put together some good examples of:

1. Here's a complicated changeset
2. I've recorded it as darcs patches
3. It takes 10 minutes to pull them from my branch x to joe random dev's 
branch y, ignoring upstream changes.


1. Here's a complicated changeset
2. I've committed it to my git tree
3. I've merged it into my branch x, along with upstream changes, to keep 
things from blowing up. It takes an hour.
4. I've now rebased it into my branch y. It takes 10 minutes.
5. Oops, I need to re-merge it with branch y upstream changes. It takes 
another hour.
6. Now I can finally pull all the changes from my working repository to 
joe random dev's working repository so he can continue to work on branch 
y with my changes...  That is almost instantaneous!

Admittedly my example is contrived, but the point is that it matches 
what I've read in discussions and people rarely note the disconnect. 
 From everything I read about "day-to-day" git workflows there is so 
much more time spent on preparing things and keeping things from 
"blowing up" and becoming unmanageable DAGs that darcs pull mostly does 
that sort of thing automatically. I'd much rather have a slow darcs pull 
than spend the time remembering which combination of merging and 
rebasing and merging again will get me the results I need after a "near 
instantaneous" git pull.  I think that sometimes we darcs fans, as proud 
as we are of the power of darcs' merge model and mostly magic "it just 
works", sometimes forget that you can't directly compare darcs pull and 
git pull, you have to take into account a whole bunch of other "stuff" 
and any benchmark, or person, that is doing so is fundamentally wrong.

Any complaints of "darcs pull is so much slower than git pull/hg pull" 
should probably be met with a swift "darcs pull does much, much more 
than git pull/hg pull alone".  Right now there seems to be a consensus 
to instead meet the complaints with an almost autonomic response "yes we 
have some performance issues and we are working on them" and I don't 
think that is quite doing us justice...

--Max Battcher--

More information about the darcs-users mailing list