Stas:
Actually there is continued overhead due to the fact that different instructions (that require a larger number of cycles to decode / dispatch) are used when calling subroutines and / or accessing memory in a shared environment.
That would be a very badly designed shared lib support. Those instructions are supposed to be cached, aren't they? From what I understand the shared libraries concept was designed to make upgrades easy, save memory and provide other benefits, without losing the speed benefits of the static libs. Reading some papers from Ulrich Drepper (http://people.redhat.com/drepper/) suggests that the latest glibc libs 2.3.x is suppose to be much better at giving you a good performance with shared libs. It also suggest that -fpic is about 3 times faster than -fPIC. This is all discussed in details at:
http://people.redhat.com/drepper/dsohowto.pdf
In any case, perlbench indeed shows a signifact performance difference, so I'd rather believe numbers than promises, untill someone proves it wrong ;) So we need to add one more tip to the bag-of-performance tricks: Use less shared libs if you can, especially avoid libperl.so.
p.s. According to the paper I've quoted above (See section 2), it takes one extra instruction for -fpic and 3 for -fPIC to do the dispatch and not a large number of cycles as you have suggested above, Paul ;) Unless we are talking about different things (and may be different architectures).
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
