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)
> <[email protected]> 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^: «590485.0481256» ¦b7201a8:
> «590489.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