Nothing personal, but I think some of your statements here aren't quite accurate and I don't want people to get the wrong idea about mod_perl/FastCGI.

FastCGI, if used correctly, allows for some fine tuning of your server. You can say, please dedicate 40 processes to this cgi, 2 processes to that cgi, etc.

That would save you some memory, but it would be a lot of work to determine the optimimum use of resources and you'd have to monitor and change it continuously as the popularity of various items on your site waxes and wanes. Technically you could do this with mod_perl if you're using a front-end proxy setup, with a different mod_perl server for each script or group of scripts. Probably only worth it under very special circumstances though.

I would imagine, just from the layout of FastCGI, that it would run more quickly and take less memory thay mod_perl Apache::PerlRun.

Less memory, maybe. Probably not better performance than Apache::Registry.

The latter has to go through it's hooks

They can be disabled if you don't need them.

share all loaded modules with anything else that is going to run (still require new modules if necessary)

You should normally pre-load your modules with mod_perl, but yes, all modules needed for all the scripts you run under mod_perl are typically loaded into the same server.

do the hit, and then tear down the package space when it is done.

Note that only PerlRun does this, and it's to protect you from any bad things you may have done with globals. If you use Apache::Registry, it does no more "tear down" than FastCGI does.

Also, consider that FastCGI adds overhead in the form of a socket call and communication to the external FastCGI process. If you run mod_perl with a front-end proxy, you take a similar hit there.