It’s really in the dispatch within Cool. Note the difference between:
for ^10000 { 1.match(/1/) }
and:
for ^10000 { "1".match(/1/) }
I’m afraid this is really uncovering a basic dispatch caching issue.
I have tried a few things, but I’m afraid this is really an issue inside
“find_best_dispatchee” in the bootstrap
> On 27 Jul 2017, at 09:37, Aleks-Daniel Jakimenko-Aleksejev via RT
> <perl6-bugs-follo...@perl.org> wrote:
>
> Oh! You're totally right!
>
> Then, it's not as bad as it looks.
>
> In fact, this commit actually *improved* the case when it has to match Str-s
> (more than 2x speedup).
>
> So perhaps the slowdown is not so critical. After all, how often do people
> match thousands of Ints…
>
> On 2017-07-26 23:55:21, elizabeth wrote:
>> 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
