Under normal CGI situations or FastCGI, what you suggest could be a real benefit.

Under mod_perl, however, because everything is kept in memory, it won't be as significant, as everything is loaded into memory and shared across scripts.

Will there be any difference? I don't know. Your best bet, in times like this, is to do a realistic benchmark of your exact system, and see if there's a difference, if it's that important to you.

Under mod_perl, the perl code gets loaded once, and lives for the lifetime of the Apache handler process. (Apache forks off several children for handling requests). That is, the time it takes to load modules is a one-time hit.

I seriously doubt that you're going to find a measurable difference by splitting common code into a .pl (or .pm) that both scripts load, unless you're doing something that kills the handler process. When the handler dies, Apache/mod_perl has to set up a new one from scratch.

Still, benchmarking is the way to prove this. Even if there's not any difference, it's a good skill to have within reach.

However, since you asked, I'll offer a bit of a guess anyway. First establish that you have a performance problem. If you don't yet know if you even have a problem, you are prematurely optimizing; and premature optimization is the root of all evil. If you don't truly have a problem, let your design decisions be guided by some other important factors like maintenance of the code, future growth, re-use, etc.

My guess is that under mod_perl, the performance difference under all of your scenarios is likely to be statistically insignificant. Other issues like network activity, SSL, possible database access, etc. will have a much bigger performance impact than similar code divided up different ways.