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

[Leszek Dubiel]

> 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/perl-maintainers/attachments/20161002/c6b09482/attachment.html>