Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #771233

Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server

From Leszek Dubiel <leszek.dubiel@dubielvitrum.pl>
Newsgroups linux.debian.bugs.dist
Subject Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server
Date 2016-10-02 23:30 +0200
Message-ID <snWuB-3G8-13@gated-at.bofh.it> (permalink)
References <snShj-11m-31@gated-at.bofh.it> <snUVQ-2Gn-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

> I see this on current sid/amd64 (Perl 5.24) too fwiw, and also in an
> amd64 chroot with Perl 5.22. I've no idea why it goes away for you on
> stretch. Can you confirm that? Are you only testing on i386 or on amd64
> as well?

Problem goes away on "stretch", perl version "subversion 1 (v5.24.1) 
built for x86_64-linux-gnu-thread-multi".
I have checked that many times.


> It looks like the difference between
>    $par = "(" . $inp . ")"; # is slow
> and
>    $par = sprintf "(%s)", $inp; # is fast
> internally is that the first one uses copy on write semantics, meaning
> it doesn't have to copy the whole string in memory. Of course, this
> is supposed to improve performance rather than degrade it.
Yes! I think the same.



> AFAICS the regexp behaviour stays unchanged, it's just the performance
> that drops. I tried some debugging with 'debugperl -Dr' but it mostly
> hides the problem by slowing down the execution by itself.
But you see the difference between "fast" and "slow" lines...
Fast -- half a second, slow -- 30 seconds.
This is dramatic performance impact.


> It would be nice to distill the issue to a smaller test case but it's
> rather sensitive to the input as you noted so that doesn't seem to be
> easy.
I have tried hard -- to cut lines, to cut program to get minimal test 
suite.
But when you remove one line it is slow, when remove 1000 lines still 
slow, when remove 1001 lines gets fast.

Also if you ADD twice that number of lines (double input in size) it 
gets FAST.... :) :)
Twice many data, 50 times faster.

I think I'm lucky to get proper data input to show the problem -- I 
can't craft very small data example to show the problem.



Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server Leszek Dubiel <leszek.dubiel@dubielvitrum.pl> - 2016-10-02 19:00 +0200
  Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server Niko Tyni <ntyni@debian.org> - 2016-10-02 21:50 +0200
    Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server gregor herrmann <gregoa@debian.org> - 2016-10-02 22:50 +0200
      Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server Niko Tyni <ntyni@debian.org> - 2016-10-02 23:10 +0200
        Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server gregor herrmann <gregoa@debian.org> - 2016-10-02 23:20 +0200
        Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server Niko Tyni <ntyni@debian.org> - 2016-10-03 21:30 +0200
          Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server Niko Tyni <ntyni@debian.org> - 2016-10-03 22:30 +0200
    Bug#839600: perl: concatenating string instead of sprintf takes all computation power of server Leszek Dubiel <leszek.dubiel@dubielvitrum.pl> - 2016-10-02 23:30 +0200

csiph-web