On Thu, Jul 29, 2010 at 14:29:35 +0200, Florian Gilcher wrote: > Okay, to stop guessing too much, I tried to come up with better numbers using > OS X built-in dtrace-facility. > > Syscall numbers: > > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28351#a28351 > > Time spend in functions (in nanoseconds): > > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28350#a28350
Nice. I've saved these to a text file and uploaded them to a tracker. > stat (and others) do not really seem to be the problem. Darcs spends the most > time waiting, spending roughly > 96% of the time in __semwait_signal, most probably because of read_nocancel > and select. If you have a look > at the call numbers, __semwait_signal is called very rarely, compared to the > calls to read, mmap, etc. OK, this bears highlighting: * that's 8 minutes out of 9 minutes fetching ghc locally in __semwait_signal * a function which is called less than 6000 times (cf. 87000 stat) So this smells like the right kind of fishy. Is this the kind of thing we may be able to just poke and suddenly find ourselves with dramatic improvements on OS X? How do we find out what this means? What's this __semwait_signal? Could the fancy graphical developer tools from Apple help with this at all? How do we run with this? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> For a faster response, please try +44 (0)1273 64 2905.
pgpTxrDU1KFnZ.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
