Check out perlrun for the details on PERL5LIB in the environment and the search path perl uses; also of interest would be the lib module. That /etc/perl directory along with several other variant directories doesn't look normal so that may be something your OS' perl set (if you're using the stock perl; which has its own issues) or you may have something setting PERL5LIB. WRT to the number of stats, that's just the way perl searches; it walks each directory on the search path looking for the requested module. The more directories you put on the search path, the more it's going to search.

So given that if you're seeing unacceptable delays one option would be to trim the search path down. Presuming you've got extra things on PERL5LIB then clearing that out in the environment would be the easiest option. If the extra directories have been compiled into your copy of perl itself then it's not so easy. You'd need to recompile your own perl without those extra directories added to the compiled in search path (but there's also benefits to having your own application perl separate from the OS' copy).

However even if you do build your own perl you'll probably wind up with about 4-5 directories to search. If even that much overhead is an issue then there may not an easy answer short of attempting something like you were thinking with a symlink farm. In that case the better option would be to look at redesigning things to not repeatedly spawn fresh perl processen which are going to need to search; if you can instead work with a persistent process (or maybe one that runs multiple passes; handwaving here without details but maybe if you could give a bit more about your environment and the "real time perl scripting" involved would probably help get you more applicable suggestions). Amortizing the stats across a longer process lifetime would help lessen the hit for any one item you process.