Last week’s blog post by masak about the “Send More Money” mathematical puzzle kind of sent me off on a little coding spree. A quick profiling run of the “loops” version of the solution quickly showed that a sizable chunk of the run time was spent inside the implementation of the “next” keyword (well, sub really.).
After just a bit of fiddling around with the implementation of “next” – which had been pessimized some time ago for some reason – together with lizmat, the benchmark went from 22s to 15s, about a 30% improvement. This is not only purely less time spent running, but also less work done GCing.
Not only “next”, but also “redo” and “last” have been improved in the same way.
lizmat also went ahead and added a :as parameter to the categorize method like the classify method already had. This lets you change what the value that came in will end up as in the resulting hash. On top of that, the classify and categorize subs also work with a :into named parameter, which allows you to supply the exact type or instance to put the values into.
Another thing hoelzro made work was the .push method for the Buf class (buffers that contain integers of a fixed size, closely packed together).
And then there’s also an interesting fix where an array of just a single pair in adverb notation would have the parser attempt to parse it as a reduce operation. Here, look:
[+] 1, 2, 3 # reduce operation [:a] # an array with a single Pair in it
This used to blow up, but works now.
Something I did was dump more information about logging and guards in the spesh dump log. I also found a bunch of places where creating P6int instances didn’t go through our integer cache that hopes to reduce the number of different incarnations of numbers 0 through 15 (now -1 through 14).
Finally, here’s a nice short blog post from domm about his experience porting a very simple script from perl 5 to Perl 6.
Looking forward to what the next week will bring 🙂 In any case, I hope yours will be fine 🙂