* Niko Tyni:
> If there are several /usr/bin/perl processes and /usr/bin/perl is
> statically linked against libperl, every process has its own copy of
> the libperl code in memory. In the case of dynamic linking, there's just
> one copy.
No, there is still only one copy in memory (or two if appl
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% improvemen
(no need to cc me, I'm subscribed)
On Tue, Apr 21, 2015 at 09:24:44PM +0100, Ian Jackson wrote:
> Niko Tyni writes ("Re: linking perl statically against libperl"):
> > If there are several /usr/bin/perl processes and /usr/bin/perl is
> > statically linked against
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
Niko Tyni writes ("Re: linking perl statically against libperl"):
> If there are several /usr/bin/perl processes and /usr/bin/perl is
> statically linked against libperl, every process has its own copy of
> the libperl code in memory. In the case of dynamic linking, there&#x
> "NT" == Niko Tyni writes:
NT> If there are several /usr/bin/perl processes and /usr/bin/perl is
NT> statically linked against libperl, every process has its own copy of
NT> the libperl code in memory.
But in the general case the ro pages still should be shared, yes?
(Containers and the li
On Tue, Apr 21, 2015 at 02:45:25PM +0200, Vincent Lefevre wrote:
> On 2015-04-19 11:43:09 +0300, Niko Tyni wrote:
> > Cons:
> > E increased memory usage on systems running multiple perl processes
>
> I suppose that this concerns only the case where one has /usr/bin/perl
> processes *and* some
On 2015-04-20 21:32:17 +0300, Niko Tyni wrote:
> On Sun, Apr 19, 2015 at 02:25:55PM +0200, Axel Beckert wrote:
> > * by providing two conflicting packages perl-base and
> > perl-base-static.
>
> dpkg cries loudly (and rightly so) if you try to remove an Essential:yes
> package like perl-base.
C
On 2015-04-19 11:43:09 +0300, Niko Tyni wrote:
> Cons:
> E increased memory usage on systems running multiple perl processes
I suppose that this concerns only the case where one has /usr/bin/perl
processes *and* some other processes that use libperl, and at most
this doubles the memory used by
-=| Niko Tyni, 19.04.2015 11:43:09 +0300 |=-
> Cons:
> F possibly increased startup time for short perl scripts
> (but that may be a non-issue due to caching anyway?)
I guess this needs some benchmarking. There is some penalty imposed by
the dynamic linker when resolving a library symbo
Hi,
Niko Tyni wrote:
> > * shipping both in the perl package and using /etc/alternatives/perl
> > to choose between the two (perl-dynamic and perl-static) for
> > /usr/bin/perl, or
>
> Even though update-alternatives is nowadays written in C and not
> Perl, I still wouldn't trust the alternat
On Sun, Apr 19, 2015 at 02:25:55PM +0200, Axel Beckert wrote:
> Niko Tyni wrote:
> > 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?)
>
>
Hi,
Niko Tyni wrote:
> 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?)
This sounds rather concerning to me. The again, I've never noticed any
13 matches
Mail list logo
