in reply to Benefiting from Devel::Profile or Devel::FastProf

AUTOLOAD is a convenient-but-expensive mechanism.   (See, e.g.:   perlsub,   AutoLoader,  or perldoc perltoot.)

Ideally, you would structure your program so that it is not necessary.   (But, maybe you can’t do that in this case.   Okay.)

Furthermore, you might want to take a close look at the Plack family of packages, which provide a very good “universal compatibility-layer / grease-joint” mechanism for running your web programs in a variety of environments, particularly including “FastCGI,” and for switching the app more easily between different deployment strategies should you in the future identify the need to do so.

One reason why I make this suggestion is that, if you decide that autoloading really is the most expeditious way to structure this application (or that the notion of changing a crufty old piece of code is just too risky), these deployment strategies might allow you to make the existing application persistent for a little while, so that the cost of autoloading can be amortized over many successive web-requests instead of being paid by each and every one.

Replies are listed 'Best First'.
Re^2: Benefiting from Devel::Profile or Devel::FastProf
by jonc (Beadle) on Jun 22, 2011 at 16:04 UTC

    Okay, Plack looks like it will help... (does PSGI need to replace CGI), however, I am confused about one thing still. Was the AUTOLOAD caused because my code called an undefined subroutine? Is it the values passed in, or the subroutine itself not loaded (would Autoloader solve it).

    I am pretty sure I can restructure my code so it is unnecessary, but don't even know where to start. Could you point me in the right direction, or do I need to supply my code?

    Thanks a lot

    p.s. your perltoot link just sends to super search, not the perldoc (if that's what you were going for)

[reply]
      AUTOLOAD is an interesting gamble. It allows a faster module load time while slowing the 1st invocation of a number of a module's subroutines/methods. If you use few of those subroutines, the gamble pays off. If you use many.....

      In your case, CGI::AUTOLOAD is the from the CGI module. To fix the situation you can either call fewer of the subroutines (probably not realistic) or do as the above response suggests and make those 1st invocations far fewer in percentage by allowing each instance of your perl program to handle more than one request.

      To see perltoot you can use perldoc perltoot on the command line, or ask for perltoot on perldoc.perl.org . perl comes with a wealth of documentation.

      TJD

[reply]
[d/l]
Re^2: Benefiting from Devel::Profile or Devel::FastProf
by locked_user sundialsvc4 (Abbot) on Jun 23, 2011 at 13:17 UTC

    As for what to do about AUTOLOAD ... well, that depends entirely upon your application.   Generally speaking, I don’t like computer programs to do much of anything “automatically,” especially not at the behest of an (untrusted, of course) end-user.   However, when dealing with a legacy application that’s now in-service, you do not always have all of the practical options that you would like.   If you know why the auto-loading is happening and if you are comfortable with the overall security of the present design (neither of which I am specifically commenting-on here ...), then the most practical strategy might well be to simply try to make the million-pound elephant that’s paying the bills just a little bit more comfortable.

    Plack is, as you can see, a family of related packages ... the reference implementation of the so-called PSGI protocol.   It does have a variety of “canned” interfaces, including ones for CGI, which allow you to adjust your existing application with a minimum of effort – for example, to run under Apache’s mod_fcgid or mod_fastcgi.   (Under the latter, which I am more familiar with, the so-called “dynamic server” option is basically designed for just this purpose, and Plack more-or-less can supply all the rest of the necessary glue.

In Section Seekers of Perl Wisdom