Date: Fri, 3 Feb 1995 06:13:52 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Cc: hackers@freefall.cdrom.com, jkh@freefall.cdrom.com, roberto@blaise.ibp.fr Subject: Re: Optimizing CVS? Message-ID: <199502021913.GAA22022@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> granularity: each sample hit covers 4 byte(s) for 0.00% of 208.85 seconds >> >> % cumulative self self total >> time seconds seconds calls us/call us/call name >> 41.5 86.635 86.635 _cputime (842) >> 17.6 123.321 36.686 _mcount (1514) >> 10.1 144.476 21.155 _mexitcount (1516) >... >Can you generate a heirarchy encapsulation profile? I can only generate standard gprof output and edit it a bit. 200K of output is too much to mail. >The totals on this one add to 100%. We can't see *where* the _cputime >is being consumed. _cputime is part of the profiling overhead. It reads the time from the 8254 clock. This takes too long. The above numbers show that my profiling takes more than 69.2/17.6 times as long as ordinary profiling, mainly due to the slow interface to the clock. The advantages of my profiling is that it is accurate for short tests and not affected by interrupt latency. >I suspect that even though a small amount of time shows in copyout, that >the page mapping and checking there is largely to blame for the time cost >(incorrectly) accounted to other routines. Copying data might bust the cache and slow everything down, but copying stat buffers won't - the user buffer is at a fixed address and the kernel buffer is probably in the cache since it is initialized just before copyout'ing. The user page containing the buffer is even more likely to be mapped in all the time than the user buffer is in the cache, and there is no software checking in copyout on 486's. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502021913.GAA22022>