On Wed, Apr 22, 2015 at 12:58:38AM +0200, Matthias Klose wrote:
> - please consider handling other register starved architectures
> like i386, e.g. at least armel and armhf.
My intention is to start treating all architectures like i386, so yes.
> - 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).
The biggest improvements (based on mining old buildd logs for the test
suite runtime as detailed in #781476) were on powerpc and armhf.
> - 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).
Right, Ian already educated me on the memory waste part. The perl world
doesn't link extensions ("XS modules") against libperl either fwiw,
neither in Debian nor upstream. (I always thought of the extensions as
plugins in a private directory rather than standalone shared libraries
that need to have all their symbols resolved.)
> - 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 ...
Thanks. I've filed #783103 about this.
--
Niko Tyni nt...@debian.org
--
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/20150422183706.GA18631@estella.local.invalid
