http://qs321.pair.com?node_id=207123


in reply to Perl v5.6.1 looking for .pmc files

10 seconds to start up sounds about right if you have 150 modules you're loading and compiling also on modest hardware. Consider using Autoloader to load functions on demand instead of at startup to avoid some of that penalty. Also consider using Devel::DProf (run Perl with -d:DProf) and dprofpp to profile your code and see where perl is spending most of its time.

A 'stat' call is common if Perl is using 'stat' to look through @INC trying to search for your modules. A given module will rarely be found in the very first place perl looks, so you're going to get a lot of these failed calls.

Though I'm not really sure why it'd be looking for a .pmc and not .pm. I haven't heard anything about that. But still, as another poster mentioned, these calls should take almost no time whatsoever. I doubt these calls (failing or otherwise) are what's causing your performance woes.

Replies are listed 'Best First'.
Re: Re: Perl v5.6.1 looking for .pmc files
by ruscoekm (Monk) on Oct 22, 2002 at 16:39 UTC

    Hi

    Re Autoloader, I did consider it, but all of the modules are required, so I have to take the hit at some point. Admittedly, there is something to be said for spreading the pain a bit :-)

    Re DProf, I find it very useful for general tuning, but do not think it will help me diagnose compile time performance issues. I find strace more helpful for that.

    Re stat calls, I already set up @INC so that only the required dirs are on the path and the dirs are in decreasing order of used modules, in order to obtain the lowest number of open failures.

    Perl does not actually issue stat calls when looking for .pm files. It just issues open calls and gets ENOENT if they are not there. stat calls are issued for .pmc, .so and .bs files (there may be others). In my example, the vast majority of stat calls are for .pmc files.

    Re the stat calls not being the problem, I can see from the strace output that they are taking around three seconds, which is a significant part of the startup time.

    Cheers, Kevin

      I do not like part of my previous reply. It is not true to say that DProf is not useful for diagnosing compile time performance issues in general. I just do not think it is helpful to my particular issue.