Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^4: Substitution unexpectedly very slow, in Strawberry

by syphilis (Archbishop)
on Aug 07, 2023 at 05:16 UTC ( [id://11153754] : note . print w/replies, xml ) Need Help??

in reply to Re^3: Substitution unexpectedly very slow, in Strawberry
in thread Substitution unexpectedly very slow, in Strawberry

It also might not be related to COW and instead be something in the regex engine that is specific to windows.

I wouldn't yet assume that it doesn't afflict Linux.
Sure, there's nothing much in the figures that hippo choroba posted earlier, but I wonder if the same thing might become evident on Linux if "1e6" is increased to "2e6" or beyond.

It's probably worth flagging with p5p

Probably, yes.
The 5.38.0 perlvar docs still warn about the potential performance hits of using $&, but then they also say (regarding $`, $& and $')
In Perl 5.20.0 a new copy-on-write system was enabled by default, +which finally fixes most of the performance issues with these three vari +ables, and makes them safe to use anywhere.
But note that it says "most of the performance issues".
And I'm still a bit curious to know whether a perl-5.38.0 windows perl built without COW would suffer the same slowdown.


Replies are listed 'Best First'.
Re^5: Substitution unexpectedly very slow, in Strawberry
by swl (Parson) on Aug 07, 2023 at 08:20 UTC

    There seems not to be a threshold value at which it kicks in. This suggests it's not COW related?.

    Modifying the code to take an argument to use as a power of 2 gives these results on Strawberry Perl 5.38. Code is below inside readmore tags.

    A doubling of the n leads to a more than doubling of the time on my machine. One would need to run it many times to be confident in the true rate of change but these numbers are close to a linear relationship when plotted with time log scaled. (For those interested in such things, the power function fitted using MS Excel is t = 8E-28**(n*21.743).)

    Edit: n in this case is the argument to the script, so the x-axis is n, not 2**n.

    Edit 2: And a polynomial function gives a better fit when using actual number of repetitions: t = 2E-11*n**2 - 5E-06*n + 0.387, with R^2 = 0.9989 (indicative-only given the sample size).

    C:\user\perlmonks>perl 15 32768 0.0403292179107666 0.0388741493225098 v5.38.0 C:\user\perlmonks>perl 16 65536 0.0916790962219238 0.0764880180358887 v5.38.0 C:\user\perlmonks>perl 17 131072 0.361366987228394 0.142138957977295 v5.38.0 C:\user\perlmonks>perl 18 262144 1.22035908699036 0.37365198135376 v5.38.0 C:\user\perlmonks>perl 19 524288 4.05149698257446 0.628846883773804 v5.38.0 C:\user\perlmonks>perl 20 1048576 21.3440728187561 3.00999999046326 v5.38.0


      This suggests it's not COW related?

      Well, it's certainly not related to the introduction of the new COW in perl-5.20.0.
      I've just fired up my old windows 7 machine that has all of the ".0" stable releases from 5.10.0.
      The demo script ran fine from 5.18 to 5.26.0 - I didn't test back any further back than 5.18.0.
      The slowdown comes with perl-5.28.0, and then persists right up to (and including) perl-5.36.0 - which is the latest perl version on that machine.
      A quick browse of the perl5280delta didn't really sound any alarms, though I noticed the following:
      [CVE-2017-12814] $ENV{$key} stack buffer overflow on Windows A possible stack buffer overflow in the %ENV code on Windows has b +een fixed by removing the buffer completely since it was superfluous a +nyway. [GH #16051] <>
      Is there possibly anything suspicious in that ? (It was the fact that it involves the removal of a buffer that led me to wonder ...)