in reply to mod_perl or CGI.pm?

I think your question should be: Which do you use and why, mod_perl vs CGI?

CGI.pm is a specific module which does a phethora of things related to interactive web site programming which is not limited to either mod_perl or CGI programming.

CGI in the generic, perl centric, sense is a perl script which is fed the input from a users web request via the CGI (1.1 for example) specification. Then the standard output of the script is hooked back to the server which may or may not 'adjust' it a little and then send it along to the requester.

mod_perl in the generic sense goes from a more or less persistant CGI kind of model up to notionally writing subroutines which are dynamically loaded into your web server which happen to be written in perl.

mod_perl in general has a response time benefit over CGI scripts. Specifically, the totally mod_perl (which means writing a sub handler{...}, making entries into httpd.conf etc), allows the script to remain loaded into memory and even to retain persistant database connections for example. This kind of integration means that to to a database query, the script merely hands the query off to the already open database connection and gets the rows back. Depending on how long it takes to set up the connection, this can save major time on a per request basis. However, this does come at a cost. Your script needs to meet a higher coding standard then a CGI called script does since the mod_perl version, being persistant, will be called many times without the clean-up a CGI script gets when the perl interpreter exits and restarts for each request. Using the less total mod_perl immersion (Apache::Registry for example) where you get a faster than CGI and slower than mod_perl standalone script, there are settings you can use to get the server to clean up the memory space for you between requests.

Summary: CGI being the baseline for comparison.

mod_perl: Speed: faster -> vastly faster, Complexity: bit more -> somewhat more complex. Memory: with the total integration method, the server keeps all the functions and their related data storage in its address space, so it can get large.

If your script will run under use strict, you are much of the way to the mod_perl level of complexity, so it's not all that much of a step. Remember that variables are not cleared out for you at script end. If you use subroutine scoped lexical variables everywhere, this isn't an issue. Also, be aware that if you have persistant database connections and apache fires up 100 children that you may have that many open connections even though not all of them are doing queries. If you have more than one database it could be children * databases of open connections.