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^: «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