[darcs-users] [issue1900] darcs seems particularly slow on MacOS X

Florian Gilcher darcs-lists at andersground.net
Tue Aug 3 07:44:53 UTC 2010


On Aug 2, 2010, at 5:35 PM, Eric Kow wrote:

> Thanks for the details,
> 
> On Mon, Aug 02, 2010 at 16:41:38 +0200, Florian Gilcher wrote:
>>> I had dumbly plugged in "4474726631771 nanoseconds in minutes" into
>>> Google's converter tool but missed a digit.  With the new 74 minute
>>> number, that can't mean what I assumed it meant.  Then what do these
>>> times correspond to?
>> 
>> Well, the call times can be way beyond the runtime. It is the sum
>> of the delta between all function entry timestamps and their corresponding exit. 
>> So, 4 threads entering __semwait_signal and waiting for 10 minutes would 
>> cause the sum to be 40 minutes.
> 
> Is there a way to get something that looks more like the runtime?

dtrace is pretty much a programming language in itself. So, you can for example emit 
any kind of log you want, like maintaining a counter how many __semwaits are active 
at one given moment. I am no expert in it, though.

Instruments is good at having a "live" look at the system, if you know how to 
configure it.

>> Well, the good question that mornfall raised in the IRC channel is whether
>> Darcs is at fault here or just the victim of a fight of some IO layer vs. the
>> operating system.
> 
> There's also this comment by Jason:
> | I have a hunch that __semwait_signal is very low level. Low enough that it
> | might be where the darcs process blocks when waiting for disk IO. If that's
> | true then I would consider long times there a symptom not a cause.
> 
> So how can we chip away at the problem?
> 
> * Is testing darcs -f-mmap useful?  Maybe it could at least give us a
>  simpler Darcs to play with?

I tested with and without mmap. Not much of a difference, except for some missing
mmaps. Mmap is said to be rather slow for small files on OS X but "rather slow"
is something like 50% and I don't know what "small" means. I might dig, if
I have the time, but I do not, at the moment.

> * Perhaps produce a cut down version of Darcs that only knows how to
>  locally darcs get a repository?  Perhaps we can keep simplifying this
>  until it's a small self-contained artificial tester.
> 
> * Perhaps produce an artificial version of the GHC repository, with
>  the same number of files, and the same number of patches but all
>  nearly empty?
> 
> What else can we do to gain insight?
> 
> Thanks!

I think it would be interesting to have a binary that basically does all
the patch copying a get would do. I think it might be worthwhile to check
out the GHC dtrace probes first.

>>> [1] And if you happen to be in an undergraduate university setting
>>>   taking a similar class <http://www.seas.upenn.edu/~cse381/>, pay
>>>   more attention! It seems 1998-Eric's effort was woefully inadequate.
>> 
>> Thanks, too late as well.
> 
> :-) That wistful note was actually addressed to darcs-users as a whole
> But maybe we're all relatively old and grumpy.

Yes, but in my case, the note hit spot-on ;).


More information about the darcs-users mailing list