Modperl speeds up the initialization phase of CGI-like scripts, so as a result a script responds faster. But the body of the script will not run faster at all.
That's not necessarily entirely true.
Because global variables are retained in the eternal interpreter of a mod_perl/httpd process, caching becomes incredibly easy, and memoization becomes even much more effective than in a CGI script.
To get the same thing in a CGI script, you'd need to communicate with a cache manager. A benefit of that is that the cache is central, a downside is that it involves overhead.
Because both mod_perl and CGI can use shared memory (or netwerk/socket communication, or file caching), that must be factored out of the comparison. This leaves mod_perl as the "winner" in runtime speed, as it has one more caching technique available. This happens to be the easiest caching technique too :)
PLP, one of my first Perl endeavours, has faster runtime in mod_perl than in CGI, because in mod_perl, there are many more cache hits.
Another way in which mod_perl can be fast that CGI can never be, is the directer printing. There's no layer of STDOUT in between. Printing with the emulated STDOUT is faster than via CGI's real STDOUT, but if you print using $r->print(...), you get an even greater performance win.
PLP uses that too. (PLP was written for performance, as it was developed for highly stressed servers that, because of the dynamic nature of the applications in question, were both for development and production.)
There are more optimizations that mod_perl does have, that CGI does not. Runtime typically is shorter a tiny bit by default, and gets further away the more mod_perl-specific syntax/functions you use.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
In reply to Re^4: Are there issues running Parse::RecDescent under Mod_Perl?
by Juerd
in thread Are there issues running Parse::RecDescent under Mod_Perl?
by johannz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |