Like require, use uses the %INC hash to keep track of what modules have been loaded and compiled. So extra calls to use for the same module won't have any appreciative slowdown effect. Same with use base -- all it does is altar the calling module's @ISA, assuming the base class has already been loaded.

Update s/INC/ISA/;# thanks almut

use CGI::Application; imports the symbols from CGI::Application (if any) everytime it's executed.
use CGI::Application qw( );, on the other hand, is just a require that occurs at compile-time.
use base doesn't seem to have much overhead.

If I have 10 calls to 'use' in various modules (same namespace definition).. how much of a hit is that for the interpreter?

Benchmark it. It's the only way to know.

Quadruple downvotes for saying "Benchmark it" to this question. The real answer is that every use() past the first is only a hash lookup. There's no abuse of the compiler and you should feel very safe in using the same thing from many places.

Caveats are of course, that $class->VERSION eq '...' or die "..." and $class->import(...) are also possibly implicated but neither of those are compiler tasks and you ought to already know if you care about the overhead of each and whether you're invoking them. I can't imagine someone using CGI::Application is going to care about the additional cost of one cheap method call.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

The real answer is that every use() past the first is only a hash lookup

I said use Module qw( ); is just a hash lookup, but use Module; isn't. Are you contradicting that?

you ought to already know if you care about the overhead of each

How? I heard import can be fairly costly. But to know for sure, one would been benchmark it.

And whether or not he ought to know is not important. He asked so I answered.

I'm working with CGI::Application

The cost of network communication dwarfs any performs concerns from using modules, unless you have a pathological @INC setup.

Have you considered making one module that loads all the modules that you need and then have the plugins inherit from that primary module?

This will not improve performance but will improve code clarity and reduce the amount of duplicate work.

I would frankly say that this sort of question is very un-likely to ever be “a legitimate cause of concern.” If you are presented with a known, measurable problem that is actually causing pain to the client's business, then you might consider doing something about it ... and that “something” will probably consist of buying newer, faster hardware. From a software point of view, the key elements should be simplicity and clarity of expression. This really is a case where, “unless it's really hollering, don't give it any medicine.”