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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5536d61e.5080...@debian.org

Reply via email to