Skip Menu |
Report information
Id: 131805
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: alex.jakimenko [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )
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
Subject: Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Date: Thu, 27 Jul 2017 08:54:55 +0200
To: "Aleks-Daniel Jakimenko-Aleksejev (via RT)" <perl6-bugs-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.9k
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... Show quoted text
> On 27 Jul 2017, at 04:06, Aleks-Daniel Jakimenko-Aleksejev (via RT) <perl6-bugs-followup@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
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:
Show quoted text
> 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-followup@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


From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )
Date: Thu, 27 Jul 2017 10:04:38 +0200
To: perl6-bugs-followup [...] perl.org
Download (untitled) / with headers
text/plain 2.8k
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 Show quoted text
> On 27 Jul 2017, at 09:37, Aleks-Daniel Jakimenko-Aleksejev via RT <perl6-bugs-followup@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-followup@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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org