In article <[EMAIL PROTECTED]>,
Bill Campbell <[EMAIL PROTECTED]> writes:

freebsd> On Thu, May 31, 2007, Akihiro KAYAMA wrote:
freebsd> >In article <[EMAIL PROTECTED]>,
freebsd> >Chuck Swiger <[EMAIL PROTECTED]> writes:
freebsd> >
freebsd> >cswiger> Akihiro KAYAMA wrote:
freebsd> >cswiger> > Hi all.
freebsd> >cswiger> > 
freebsd> >cswiger> > What is the right way to measure wall-clock time in 
profiling on FreeBSD?
freebsd> >cswiger> 
freebsd> >cswiger> The time shell builtin command or "/usr/bin/time -l 
freebsd> >cswiger> 
freebsd> >cswiger> The latter variant displays the rusage struct (ie, from "man 
freebsd> >
freebsd> >Thanks for your response.
freebsd> >
freebsd> >Yes, we can know whether the program is I/O bound or CPU bound by
freebsd> >time(1). But it is still unclear which part of the program is really
freebsd> >waiting for I/O. So profiling is needed for tuning, although CPU time
freebsd> >profiling gives me non-distinct result on I/O bound programs.  It is
freebsd> >reason why I want wall-clock time profiling.
freebsd> Wall clock time doesn't generally tell you anything reliably
freebsd> useful on a multi-tasking system as it's very dependent on other
freebsd> system activity.  I had many fights back in the mid '70s with
freebsd> people in accounting who wanted to bill wall-clock time on
freebsd> Burroughs main frames which generally had 20 programs in the mix
freebsd> at any time (I guess they were accustomed to IBM 360s that
freebsd> couldn't walk and chew gum at the same time :-).

Yes, I know UNIX was born as TSS in 1970. And today I occupy my FreeBSD
box. It is not necessary to share it with my colleagues.  Thanks to
Moore's Law and so many FreeBSD guys.

It is easy to prepare a dedicated machine for debugging purpose and
run a test program only.  Daemons are still running in background but
they are almost asleep (load averages: 0.00) so will not be critical
on wall-clock time profiling.

Wall-clock time profiling will be useful to know what routines/system
calls take time in complex code, especially I/O related routines.

Akihiro KAYAMA
_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to