Looking at the profile of

    (^10000).grep({!/1/}).elems.say

the first 5 entries (responsible for 70% of CPU in that example) have nothing 
to do with matching, but everything with trying to find the right dispatchee.  
And it looks like this is basically caused by:

    $_ = 1; /1/

Because $_ contains an Int, this becomes a very slow path.  Compare this with:

    (^10000)>>.Str.grep({!/1/}).elems.say

which is 3x faster, even when using a sub-optimal hyper.

Investigating further...

> On 27 Jul 2017, at 04:06, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
> <perl6-bugs-follo...@perl.org> wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #131805]
> # in the subject line of all future correspondence about this issue. 
> # <URL: https://rt.perl.org/Ticket/Display.html?id=131805 >
> 
> 
> See this benchable6 output: 
> https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46
> 
> If you look closely, benchable has not only built the graph across all 
> releases, but it also bisected the performance drop to the exact commit. Here 
> is that commit: 
> https://github.com/rakudo/rakudo/commit/b7201a8f22338a906f2d8027a21387e8f5c77f41
> 
> This was double-checked with committable6:
> <AlexDaniel> c: b7201a8^,b7201a8 (^99999).grep({!/1/}).elems.say; say now - 
> BEGIN now
> <committable6> AlexDaniel, ¦b7201a8^: «59048␤5.0481256» ¦b7201a8: 
> «59048␤9.0262629»
> 
> So it is ≈5 seconds before vs ≈9 seconds after. A significant performance 
> drop even if we assume possible bench noise.
> 
> This was noticed because of this ticket: 
> https://github.com/perl6/doc/issues/1425
> 
> See also IRC discussion: 
> https://irclog.perlgeek.de/perl6/2017-07-27#i_14927626
> 
> And maybe coverable output on HEAD if it may help you: 
> https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c
> 
> Note that whether it's {!/1/} or {/1/} doesn't really matter: 
> https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

Reply via email to