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