An embedded perl interpreter cannot replace mod_cgi, as mod_cgi is not limited to running perl-scripts; you can run any executable using mod_cgi. Could be compiled C binaries, or a shell script, as long as it 'talks' CGI.

The two main ways to make scripts faster, are to keep the perl interpreter in memory, and to keep the compiled scripts in memory. In fact, I don't see how these two could ever be separated; the perl interpreter also maintains the variable space, and as far as I know, there is no way to 'reset' it. There are many ways to alter the symbol table, and no guaranteed way to track these alterations. Because of this, there is no way to provide each request with 'clean memory' without reloading the perl interpreter.

Mod_perl already tries to solve these issues by creating a separate package for each cgi-script, thereby at least separating the variable space for the scripts. But it's trivial to manually access variables outside of this package. And it's not trivial to 'reset' the used variables after each request...

The nature of perl and it's interpreter make it very hard to establish what you propose. It's possible for the most part, but would require all cgi-scripts to 'play nice', and any script that doesn't can cause big problems. And harnassing memory usage is always tricky with perl; you have to know quite a bit about the perl internals to understand where it's all going...

PHP usage of variable-space was designed for this purpose, which is why it is capable of so much.

A possible way to do what you want may be to have a 'cgi-server' wrapped around all cgi-scripts, and have Apache pass all request to this other process. This would only require ProxyPass'ing from Apache, and a simple server-wrapper around the cgi scripts. In fact, I can't imagine such a wrapper doesn't exist yet. This would require the server to run this extra process though, and would possibly create extra maintenance problems.

A solution sometimes used is to use a separate mod_perl enabled Apache instance with a limited number of threads to handle the script request, and have a 'big' non-mod_perl Apache as the front-end. This makes use of existing tools, but limits the amount of problems that can arise from using mod_perl.