In the last journal entry, I told a lengthy story about an XS and perl API learning experiment that resulted in a module that scans subroutine opcodes at run-time to find candidates for replacing with an XSUB.
Now, the trouble with that approach is that scanning the op tree for such methods takes a long time. It's a cool idea and maybe even sensible if you have an existing system with a lot of code that is long running and needs to be as fast as possible, but let's face it: No sane person would like to add something as fragile as an op-tree scan to such a system. (Though you have nothing to lose except compilation time.)
So I ripped out the XS code with the cleverish fake currying that generates the getters, put it in its own module, added an implementation of setters (that was really trivial in XS), and uploaded it to CPAN. The result is potentially the fastest accessors you can get for a Perl hash-based object bar hand-rolled XS. And that would only save a C array access, two C struct accesses and perhaps some slight book-keeping.
On a related note, I continued hacking on B::Utils which I used for the original AutoXS hack.
For all readers who'd rather jump from the nearest TV broadcasting tower than look at the modules that start with a B: B::Utils provides convenient tools to inspect the op tree that is generated by the perl compiler. Among those, there is a function called opgrep which - you guessed right - matches conditions against an op tree. These conditions are specified as nested hash structures that resemble the op tree itself.
In the past days, I added a method to the B::OP objects that can dump the op tree as such a pattern for use with op_grep(). This should make it much easier to extend the AutoXS module for more complicated scanning. Additionally, opgrep() can now, while scanning, extract ops from within the op tree that it is traversing. That way, it's no longer necessary to walk the op tree yourself in order to extract information after you've verified that it matches your expectation.