New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.grep-ing Ints with a code block is now almost twice slower ( .grep({/foo/}) ) #6414
Comments
From @AlexDanielSee 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: rakudo/rakudo@b7201a8 This was double-checked with committable6: 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: Raku/doc#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 @lizmatLooking 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...
|
The RT System itself - Status changed from 'new' to 'open' |
From @AlexDanielOh! 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:
|
From @lizmatIt’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
|
Migrated from rt.perl.org#131805 (status was 'open')
Searchable as RT131805$
The text was updated successfully, but these errors were encountered: