Team Rubber BlogTeam Rubber talks on the Internet in a blog

I haven’t mentioned any free time coding on this blog for a while, but I thought some people might be interested in a project I released a couple of days ago.

Pynoceros is a python port of the javascript parser from the Rhino javascript interpreter. (It’s a fairly straight forward language conversion at the moment – so don’t expect it to be pythonic!)

Why? Well Rhino is a  stable, and well used code base, and it forms the basis for the YUI Compressor – which I’ve often wanted a python version of.

My version of the YUI compressor is almost done (I’ve just got to find time to add all the license information and prepare the release), but in the mean time I thought I’d release pynoceros for anyone who’s interested.

I’ve been reading the python interpreter fairly closely recently (more on that to come in a later blog post), and I was surprised by how much optimisation there is around function calls, dispatching them differently depending on their parameters (expected and supplied)*.

I was going to include this in a later post, but to keep that shorter here’s a quick example. Let’s take these two massively simplified functions.

def a(spam, eggs):
    return

def b(spam, eggs=None):
    return

Calling a(0,1) is fast because the interpreter skips the keyword argument tests and pushes the parameters direct onto the stack for the new function.

Next came b(0,1) – which takes roughly 10% longer on my machine as there is more for the interpreter to set up.

Calling with keyword arguments is far slower though – with:

a(spam = 0, eggs = 1)

and

b(spam = 0, eggs = 1)

both taking 50% longer than the fastest opportunity (and a negligible difference between the two). Obviously a large part of the 50% increase is setting up the names of the parameters on the stack – but if you read the interpreter source you’ll see there’s far more than that at play (including quick lookup of “self” for bound methods etc.).

(obviously most non-trivial functions will spend a significant time within the function body – which will reduce the relative performance boost – but there’s sure to be the odd situation where it’s worth knowing this.)

* n.b. – I was looking at the 2.5 tag of python, but as far as I can tell none of this code seems to have changed so far in the 3.x trunk.

(I’m going to start off by emphasizing that this is not for production use, it is just a bit of harmless fun while I was looking at the structure of python’s bytecode, and I thought it might be interesting reading for others)

There have been quite a few hacks in the past to add tail-call optimisation to python – normally in cross-interpreter python, but while I was playing with the byteplay module thought I’d have a go at writing a function that re-compiles a function with basic tail-call optimisation inserted.

My method is basic, and converts tail-recursive calls in a (pure) function into jump statements.

(more…)