Take the 2-minute tour ×

I'm developing some CGI scripts and I'm trying to find a solution to decrease the "starting time" produced when I import a lot of modules with "use".


The solutions provided are nice, but the scripts I'm working runs both in console and CGI mode checking if some typical HTTP environment variables are present.

In "console mode" they dump the data "normally", and in "html mode" they make some realtime replacements and send other HTTP headers to the client.

I'd like to improve the startup time in both cases.

share|improve this question
are you creating a new process for each request ? –  M. Utku ALTINKAYA Mar 27 '09 at 18:35
yes, but that's not exactly my main problem, since some scripts runs both in console and CGI mode ^^ –  mndg Mar 27 '09 at 18:48

6 Answers 6

  • Make sure this is actually your bottleneck
  • Only import modules you need
  • Make sure you aren't having to search a zillion places to find them
  • Consider having processes with costly startup run hot (e.g. as a daemon) and use lighter weight CGI scripts to start them
  • Look into various accelerators rather than doing full CGI from a shell (depends on what you're using to serve the pages).
share|improve this answer

How about using mod_perl to run your scrips?

share|improve this answer

Consider using CGI::Fast in order to start one perl process to handle multiple requests. It took me very little effort to change some of my big CGI scripts over to CGI::Fast. Unlike mod_perl, it's very easy to run CGI::Fast on hosting sites because you can restart your scripts without restarting Apache (at least that's what my hoster told me when I asked for mod_perl).

share|improve this answer
+1 # also good to note, FCGI is not server implementation bound, making it massively much more portable. –  Kent Fredric Mar 27 '09 at 18:38
Sounds nice, and If the scripts runs in console mode too? more tip? thx :) –  mndg Mar 27 '09 at 18:43
It is possible to restart your program without restarting mod_perl. But FastCGI is simplier. –  Alexandr Ciornii Apr 26 '09 at 23:30

You could always try the less pragma:

use less 'starttime';

Of course, that is system dependent*. Your best bet is to use mod_perl or one of the FastCGI modules: CGI::Fast, FCGI, etc.

If it needs to be fast from the commandline you may want to move to a client/server architecture (which is all FastCGI is).

* warning no systems currently implement a starttime option for the less pragma.

share|improve this answer
wops, it seems not to be very portable ^^ –  mndg Mar 27 '09 at 18:52

Well, others already have suggested that CGI might be your problem here, so I'll consider that you can't remove CGI from the picture.

You might want to consider this old article. Apparently one source of slow startup time is a huge @INC so consolidating everything in a short PERL5LIB seem to help tremendously (that seems to be a fair assumption, but I never tried it).

Alternatively (or additionally), if you don't mind paying some price at run time you can use Class::Autouse


share|improve this answer

Try using SpeedyCGI or Persistent Perl.

Both implement roughly the same idea: Instead of the Perl interpreter, they a wrapper that parses the program and keep it in memory, thus saving the time required for initializing the interpreter and parsing on every run.

This should work fine with the dual-environment setup you described which would/might not be the case when using CGI::Fast or mod_perl.

EDIT If this helps, fine. If it doesn't, you'll have to measure where your script spends its run-time.

share|improve this answer

Your Answer


