Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

perrin (4270)

perrin
  (email not shown publicly)

Perrin is a contributor to various Perl-related projects like mod_perl, Template Toolkit, and Class::DBI. He is a frequent speaker at OSCON, YAPC, and ApacheCon, and a contributor to several perl-related books.

Journal of perrin (4270)

Thursday June 12, 2008
02:43 PM

Why don't profilers default to wall time?

[ #36675 ]
It seems like at least once a week someone on PerlMonks or a mailing list I'm on is confounded by their profiler results. (Recent example here.) They look at the output, and nothing seems to be taking much longer than anything else, so they start chasing phantoms like method call overhead.

The problem is that they're measuring the wrong thing. Is your program taking too much CPU, or is it taking too much time? If you're running on a computer built in the last decade, it's probably time that's the issue. So why do we profile CPU cycles?

Nearly every program outside of the scientific community (or other math-heavy situations) is I/O bound. You don't see the I/O when you profile CPU time. It looks like it's not even there.

I've seen this happen so many times on the Class::DBI, Template Toolkit, and mod_perl lists. People show up all desperate to eliminate every method call or rewrite their templating module in C based on a profile they did. Then you tell them to do one by wall time and they find out that 99.9% of the run time is actually waiting for database calls to come back or something similar.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.