in reply to Re^2: Why can code be so slow?
in thread Why can code be so slow?

True - and irrelevant except to the extent of being able to say "it would be even worse than it is actually measured performance-wise if it didn't do that." The test script for CGI.pm consisted of this: 
#!/usr/bin/perl

use CGI;
my $cgi = CGI->new;
my $value = $cgi->param('a');
print "Content-Type: text/plain\015\012\015\012a=$value\n";

[download]
Note that I do *NOTHING* not necessary for the script to execute. If you can suggest a faster way than to use CGI.pm in a script than that, I would be fascinated to know what it is.

Replies are listed 'Best First'.
Re^4: Why can code be so slow?
by chromatic (Archbishop) on May 01, 2007 at 20:44 UTC
    True - and irrelevant...

    It's extremely relevant, if Perl doesn't actually compile all of that code. If your point was that Perl has to find and read all of those blocks from disk, that's fine. I didn't get that impression from your notes, however.

    If you can suggest a faster way than to use CGI.pm in a script than that, I would be fascinated to know what it is.

    Make sure CGI.pm is in the first directory in @INC.

    To do this benchmark properly, make sure all of the modules you want to load are in the same directory, and preferably the first directory in @INC. If you really want to compare the weight of one module over another, you have to remove all other variations, and disk IO can be a very large variation, especially if compilation and execution time is minimal as in this case.

[reply]
[d/l]
[select]

      Fine. For your edification.

      speedtest-cgi-minimal.pl 

      #!/usr/bin/perl
use CGI::Minimal;
my $value = CGI::Minimal->new->param('a');
print "Status: 200 OK\015\012Content-Type: text/plain\015\012\015\012a
+ = $value\n";

      [download]

      speedtest-cgi-pm.pl

      #!/usr/bin/perl
use CGI;
my $value = CGI->new->param('a');
print "Status: 200 OK\015\012Content-Type: text/plain\015\012\015\012a
+ = $value\n";

      [download]

      I ran the test both with them hardlinked from the first @INC directory and then again with them in only their normal locations. The test was a 60 second run with 30 parallel fetches of http_load of each on a P4 with hyperthreading enabled at 3.06 GHz (I used a second fast machine to execute http_load for the requests). The version of Apache was 2.2.2 and the version of Perl was 5.8.8. 

                       in first @INC Directory          Normal
CGI.pm (3.25)          21.5/second               21.5/second
CGI::Minimal (1.26)    73.8/second               73.6/second

      [download]

      The difference is below the system noise floor. Any other criticisms of my methodology?

      My 'irrelevant' statement point was that it doesn't really matter a whole lot that if CGI.pm didn't do its clever little trick with subroutines stored in hash strings that it would be even slower than it is right now. It still is measured to run much slower than any of the alternative CGI parameter processing modules and that difference is simply due to its raw size.

[reply]
[d/l]
[select]
        so basically, if I load 5 modules of 100k in size each; I would be throwing away 500k in size every single time I start this CGI; where mod_perl would be keeping 500k in memory and use the rest in shared memory?

        Is mod_perl the only possible way to keep a script execution size and footprint as low as possible? What about scripts not running on apache using those 5 modules of 100k in size each?

        I was thinking for all these years Perl would allocate its needed memory for the routines which are actively used; not using memory for the unused ones..

[reply]
Re^4: Why can code be so slow?
by freakingwildchild (Scribe) on May 01, 2007 at 21:11 UTC
    This makes me wonder if I better keep using my own routines to get my parameters etc instead of using CPAN modules. Do these modules take their entire size as overhead or only the subroutines which get executed? I've also noticed a few weird things with a package I've made slurping more CPU (and memory) than it should take; I only use XML::Twig and XML::Simple in that package (for backwards compatibility for now)

    Visual::XML::BEGIN is which I really wonder about ; only 3 calls and 17.5 time for executing these; while its merely a package of 3 routines made as proxy to be backwards compatible using XML::Twig with XML::Simple calls... 

    %Time ExclSec CumulS #Calls sec/call Csec/c  Name
 42.0   0.120  0.188     16   0.0075 0.0118  Visual::XML::Podcast::BEGIN
 17.5   0.050  0.278     10   0.0050 0.0278  main::BEGIN
 17.5   0.050  0.060      3   0.0166 0.0199  Visual::XML::BEGIN
 3.50   0.010  0.010     47   0.0002 0.0002  strict::bits
 3.50   0.010  0.010      1   0.0100 0.0100  utf8::AUTOLOAD
 3.50   0.010  0.010     29   0.0003 0.0003  XML::Twig::BEGIN
 3.50   0.010  0.010      3   0.0033 0.0033  LWP::Simple::BEGIN
 3.50   0.010  0.010      1   0.0100 0.0100  Visual::XML::Podcast::itunes::BEGIN
 3.50   0.010  0.010      7   0.0014 0.0014  IO::File::BEGIN
 0.00   0.000 -0.000     31   0.0000      -  strict::import
 0.00   0.000 -0.000      1   0.0000      -  vars::BEGIN
 0.00   0.000 -0.000      1   0.0000      -  warnings::BEGIN
 0.00   0.000 -0.000      3   0.0000      -  warnings::register::import
 0.00   0.000 -0.000      6   0.0000      -  warnings::register::mkMask
 0.00   0.000 -0.000     29   0.0000      -  vars::import
[reply]
      It looks like a lot of your time is being spent BEGIN time, at startup. You might want to try the approach I suggest here: Re^3: Why can code be so slow? to see if startup time is dominating your application.

      If it is, the best solution is probably to avoid repeated startup (by using mod_perl or FastCGI) rather than optimising startup by avoiding CPAN modules.

[reply]

In Section Seekers of Perl Wisdom