The mailing list for listmasters using Sympa

[Dan Pritts <address@concealed>]

On Thu, Sep 30, 2004 at 08:57:59AM -0700, Dean Ericksen wrote:
> 
> I was almost certain this was the case. I recompiled yesterday (same
> result), but I suppose that I'll need to tinker with this process so
> that the shared library is doing the heavy lifting rather than the
> binary itself. Is there a web page that you know of that speaks to this
> option? I assume that perl.org and cpan have lots of detailed info, but
> I'm looking for more digestible fare. 


This is from the INSTALL document at the root of the source.
Looks like I was wrong about it not affecting performance. 

there is more detail on the build process later in this doc.


perl v5.8.2          Last change: 2003-11-05                   19

User Contributed Perl Documentation                    INSTALL(1)


     Building a shared Perl library

     Currently, for most systems, the main perl executable is
     built by linking the "perl library" libperl.a with
     perlmain.o, your static extensions (usually just
     DynaLoader.a) and various extra libraries, such as -lm.

     On some systems that support dynamic loading, it may be pos-
     sible to replace libperl.a with a shared libperl.so.  If you
     anticipate building several different perl binaries (e.g. by
     embedding libperl into different programs, or by using the
     optional compiler extension), then you might wish to build a
     shared libperl.so so that all your binaries can share the
     same library.

     The disadvantages are that there may be a significant per-
     formance penalty associated with the shared libperl.so, and
     that the overall mechanism is still rather fragile with
     respect to different versions and upgrades.

     In terms of performance, on my test system (Solaris 2.5_x86)
     the perl test suite took roughly 15% longer to run with the
     shared libperl.so.  Your system and typical applications may
     well give quite different results.


danno