In the same situation a few years ago, we came up with the same idea and went with it. It has worked well for us.

benefits:
1. If I remember correctly, we saw noticeably lower memory usage and a just-barely quicker startup time.

2. Merging changes, patching old releases, and working together with a large team is much easier. Instead of constantly merging changes to the same large files, now we're typically each working on tiny files that don't affect one another.

3. Copying code from one script to another doesn't result in annoying errors when we forget to require the right lib files. We require one lib file with the AUTOLOAD and it takes care of the rest, including nice error reporting and logging when something goes wrong (sub not found, sub doesn't compile, etc.).

I've really grown to like our current system, more because of #2 and #3 than #1.

drawbacks:
Once in a while you're going to run into wierd things caused by the autoload. I think we had a problem with sort subs in other packages, for example:

package A;
my @sorted = sort B::notYetLoaded @unsorted;
[download]

We've found workarounds for all of the problems, but each one took time.

Also, I recently tried to use inheritance (we only recently started doing much object-oriented programming). Working with our AUTOLOAD (while trying to preserve its behavior for all our existing code) was ugly enough that I gave up inheritance for now.

I agree with others above who have suggested mod_perl and other cleaner solutions -- you'll get a much bigger boost from mod_perl than from this -- but if those 100K lines of code weren't written with mod_perl's persistence in mind, that could be daunting.

-Joe