The Optimization That Didn't Matter

by chromatic

I've spent several hours optimizing Parrot over the past few months. In particular, I've concentrated on the build process for Rakudo (Perl 6 on Parrot), as it exercises a lot of parts of Parrot. We don't yet have accurate numbers on the improvements, but rough figures show that the parts of the build process I've optimized will be about twice as fast as they were three months ago, despite Rakudo having grown tremendously since then.

Some of this comes from luck, some comes from a deepening knowledge of Parrot internals, a lot of it comes thanks to Callgrind and KCacheGrind, and some of it is experience. My instincts are improving.


3 Comments

Daniel Berger
2008-05-16 07:22:54
On a possibly unrelated note, have you ever used Coverity? I don't know if it would help with optimizations or just security.


http://www.coverity.com/

Chris Jones
2008-05-16 09:22:35
You wrote: "One of the best optimization strategies is to understand what happens frequently and what happens infrequently, and to try to make infrequent things mostly free — or at least cheap. Signal delivery in Perl 5 is pretty infrequent."


This sounds exactly backwards to me. Making the frequent things mostly free or at least cheap would be where the big rewards lie.

Christopher E. Stith
2008-06-09 08:48:00
I think Mr. Jones has misread the strategy in this context.


It's not a matter of paying closer attention to code which runs infrequently, but to code that runs often but actually needed infrequently. What the author meant is that when you're not making use of a feature, it should be using as few cycles as possible.


The improvement in question was a question of not checking for signals needing to be delivered to user code unless a signal handler was present. Currently, there's a check even if there's no user-installed signal handler present to receive signals.