Re: linking perl statically against libperl
On 04/19/2015 10:43 AM, Niko Tyni wrote:
> Hi,
>
> I'd like to start linking /usr/bin/perl statically against libperl on
> all architectures instead of just on *i386 like now. See #781476
> for some more details. I'm looking for input on this.
>
> Pros:
> A we can treat all architectures the same way -> simpler packaging
> B slightly improved performance (4%-15% depending on the architecture)
> C removes the current kludge where libperl.5.20.so is bundled
> with perl-base on !i386 and the shlibs lie
> D makes sure perl-base (which is Essential:yes) stays robust
>
> Cons:
> E increased memory usage on systems running multiple perl processes
> F possibly increased startup time for short perl scripts
> (but that may be a non-issue due to caching anyway?)
>
> I'd very much like to achieve A and C while keeping D. An alternative
> would be to take the performance hit on *i386 too and link libperl in
> dynamically on all architectures, but move libperl.5.20.so into the
> libperl5.20 package and make perl-base Pre-Depend on that. Presumably
> this should work too, but it does make perl-base dependencies a bit
> more complex.
>
> I note that this would match what python is doing AFAICS, so I
> suppose the memory usage concerns aren't that critical?
- please consider handling other register starved architectures
like i386, e.g. at least armel and armhf.
- not sure if I would call a >10% improvement as "slightly improved".
note that this goes away when somebody decides to build such a
binary with -fPIE (afaics not only on register starved archs).
- note that in Debian python extensions aren't usually linked with
-lpythonX.Y. This is done to not depend on multiple python versions
when building an extension for multiple python versions in a single
binary package, but also to not load the shared library. I don't see
a memory waste here. Of course, the shared library is loaded when
an application is started using an embedded python interpreter (vim).
- please experiment to build the perl binary using pgo and lto. Usually
one of these gives you an additional 10% performance improvement, at
least seen for python. pgo should be pretty safe, lto depends on the
architecture and compiler version, so expect to do some work yourself ...
Matthias
Reply to: