will that slow down processing?

However, that's not where the slow part of your program is. Instead use a profiler such as Devel::NYTProf to find out where the real problems are, and optimise those.

You can look for yourself at the code for Exporter, and see that it's unlikely that adding a few items to the EXPORT list will impact your code's performance meaningfully. If you're facing performance issues, you'll want to look elsewhere. And as daxim said, you should profile rather than take wild guesses.

Where there may be some benefit is when using modules that autoload or eval subroutines into existence at import time. But even with those sorts of modules, there probably just isn't enough going on to worry about unless your profiling demonstrates a need to investigate this corner of your code base further.

There are still advantages to exporting/importing only what you need. The most oft-cited one is avoiding namespace pollution in the calling code. Another advantage from the perspective of the calling code is that by specifying exactly which subroutines to import on the use line, the calling code becomes more self-documenting.

I may be wrong, but my understanding is that when you use or require a module, Perl is compiling the whole module anyway, including the subroutines which are not exported, so that the only difference between exporting or not exporting a function (putting its name in @EXPORT or @EXPORT_OK) would really be updating the program namespace, which probably is not measurable. The fact that you don't export a subroutine does not mean that you don't use it, it only means that it is not intended to be used directly by the main program, but it may very well be used internally by other functions of the same module. Is this view wrong? Am I missing something?

No, I think that you are exactly correct.   The module will be compiled, regardless, if not done already.   Then, any name in @EXPORT will be added to the global namespace.   If you provide a list of routines in your use statement, they must be in @EXPORT_OK.

Nothing will lead to any sort of performance problem.   Everything goes through a one-time “compile (on the fly)” process and, once done, never happens again (AFAIK) for the duration of the run.   If there is a performance issue in this app, “red herring ... look elsewhere.”

I almost never export anything from modules I write. I almost always:

use Wibble qw();
[download]

when I use modules. I means I have to:

Wibble::Wobble();
[download]

when I need to call Wobble(), but at least I know where Wobble() lives that way even minutes, or months, after I wrote the code.

Using OO largely avoids the name space pollution problem that these measures seek to avoid without cluttering the code with explicit name space references.

True laziness is hard work