Re^2: Benchmark.pm ing -- and a little confused

So I guess, because a large portion of the actual processing time is on a remote server and the local server is just waiting for most of it's "wallclock" time that is the reason for the large difference in percentages?

So in this case the wallclock time would actually be a better gauge of the comparison than the CPU time, right?

Comment on Re^2: Benchmark.pm ing -- and a little confused

Replies are listed 'Best First'.
Re^3: Benchmark.pm ing -- and a little confused by Roy Johnson (Monsignor) on Mar 14, 2005 at 22:02 UTC
Yes, if the code of interest is being run on a remote machine, then wallclock seconds are your best measure. Caution: Contents may have been coded under pressure.	[reply]
Re^4: Benchmark.pm ing -- and a little confused by halley (Prior) on Mar 15, 2005 at 17:40 UTC
Just remember, if the wallclock time is significantly affected by things unrelated to the actual CPU time spent running your script, then your script isn't necessarily the bottleneck, and may not be your prime target for any optimization work you've been planning. -- `[ e d @ h a l l e y . c c ]`	[reply]