dws has asked for the wisdom of the Perl Monks concerning the following question:

My team has a problem. We have a fairly large code base, and we've been having problems getting the various profilers to work on it. In some cases, the profilers crash and burn. In other cases, we get numbers that we just don't trust.

We're embarking on an effort to fix one or more (but probably only one) of the existing profilers, with the intent of contributing any general fixes back to CPAN. To gear up, we're looking around for current information about what kinds of things (eg., Perl constructs, specific modules, etc.) confuse the current generation of profilers. (We do a few marginally legal things with typeglobs, for example.) We're reading up on existing bug reports, but field reports are useful, too.

If you've run into difficulties getting Perl code to profile, especially if you've worked around those problems, please post what details you can. Even "I suspect the problem may have been _____" might help. The info we gather will help us craft experiments and test cases, so that we can make the best of our limited time and budget.

Thanks.

Edited by planetscape - moved to Seekers of Perl Wisdom

Replies are listed 'Best First'.
Re: Gathering data on Profiling woes
by perrin (Chancellor) on Nov 01, 2005 at 15:59 UTC
    I can tell you two common mistakes people make when profiling. The first is measuring CPU time in an application that is I/O bound. Devel::DProf shows CPU time by default, and that's pretty much useless for an application that uses a database or does other slow activities that are light on CPU.

    The other problem I see is when people try to profile mod_perl apps but load their code before initializing the debugger. If you load code during startup in mod_perl, you have to start the debugger first, because the profiler uses the debug hooks. If you don't do that, you only get back info on the code loaded later, and it looks wrong and useless. (This is all described in the mod_perl docs.)

[reply]
      (I work with dws)

      > The first is measuring CPU time in an application that is I/O bound.

      *nod* Our default quickie-profiling command defaults to wall-time instead of cpu-time: 
      perlp is a function
perlp () 
{ 
    perl -d:DProf "$@";
    dprofpp -r -O 30 >"${1}.prof";
    cat "${1}.prof"
}

      [download]
      > try[ing] to profile mod_perl apps but load their code before initializing the debugger.

      We can't even profile our code which gets run under mod_perl in a non-mod_perl context (profiling it while under execution by one of our unit tests, for instance, or while driven by a targeted one-off script).
[reply]
[d/l]
        Not sure what you're getting at in that last bit. You don't need to run your mod_perl code in a non-mod_perl enviroment to profile it. That isn't really related to not init-ing the debugger under mod_perl when profiling though, which is a very common mistake.
[reply]
Re: Gathering data on Profiling woes
by salva (Canon) on Nov 01, 2005 at 12:45 UTC
    I am the maintainer of Devel::SmallProf and the author of Devel::FastProf. If those are among the ones you have tested I would like to get your complaints and bug reports!!!
[reply]
Re: Gathering data on Profiling woes
by samtregar (Abbot) on Nov 01, 2005 at 18:17 UTC
    Back when I was working on Devel::Profiler I had a hard time profiling the following modules: 

    UNIVERSAL Time::HiRes B Carp Exporter                                 
+      
Cwd Config CORE DynaLoader XSLoader
AutoLoader

    [download]

    That's the default bad_pkgs setting which skips trying to instrument subs in those modules.

    If you haven't decided which profiler to fix, please consider fixing Devel::DProf. If that module worked better the rest would be largely unnecessary. Failing that, you might consider working on Devel::Profiler, which was created as a last resort when I failed to fix Devel::DProf to work on Bricolage.

    -sam

[reply]
[d/l]
[select]

      FWIW: If there is going to be a thoroughly revamped profiler, I'd prefer it to something like Devel::SmallProf. It's line-by-line granularity seems considerably more useful to me.

      I also like it's ability to control what gets profiled through the inclusion of in-line directives (global assignments.

      The downsides are that it is rather slower than some other profilers and doesn't work with or have the equivalent of dprofpp. That said, it's native output format is emminently usable, and easily manipulated with an editor, Perl or most other text-based tools like grep etc.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re: Gathering data on Profiling woes
by monarch (Priest) on Nov 02, 2005 at 03:53 UTC
    Profiling a forking app can be particularly challenging.

    Advanced degree of difficulty if the forked component exits using the quick and exceptionally ungraceful POSIX::_exit( 0 ); command..

[reply]
[d/l]

Back to Seekers of Perl Wisdom