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 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. Well, I have not investigated further and I do not have a lot of experience with both lower level darcs and OS X internals, but this looks strange. Darcs version was the recent beta release + mmap. The repository was the "optimized pristine" version of the GHC repos. Regards, Florian _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
