Bytecode optimisation

[Corran Webster]

In article <37411E7D.4B032AD5 at lemburg.com>,
M.-A. Lemburg <mal at lemburg.com> wrote:
>[Byte code optimizer]
>
>In case you do consider a rewrite, you might try to convert the
>peep hole optimizer written by Skip Montanaro to make use
>of the bytecodehacks package:
>
>	http://www.automatrix.com/~skip/python/

Thanks - I had heard about this project, but couldn't find the webpage
when I was working on the weekend.  And thanks to the others who pointed
out this work.

I think the true strength of this are in the patches to the Python
source; the actual peephole optimizer would need to be re-written to
take advantage of bytecodehacks, I suspect.  What might make sense
would be to ensure that a bytecodehacks optimizer can be slotted into
the package, but I think if the bytecodehacks optimizer should be made
pure Python, so all you need in C is the (fairly standard) new module.

>About adding type information to variables:
>
>Wouldn't it be possible to make the optimizer recognize
>the following type of assert statement and then use the
>implicit information contained in it...
>
>assert type(x) is types.IntegerType
>x = x + 2
>
>There are many advantages to this construct, since it can
>be used to debug *and* optimize code. It also is perfectly
>valid Python and shows the programmers intent pretty well,
>IMHO.

This is the way that I was thinking - my one worry was the fact that
"types" could of course be anything.  But it's probably fair enough
to say that if you are playing with redefining the meaning of basic
modules, you deserve what you get :)

In fact there could well be a case for allowing an optimisation setting
where builtins like "range" are assumed to have their standard meaning.

>BTW, the same could be done to mark and check constant variables:
>
>markconstant(x)
>...
>assert isconstant(x)
>
>with markconstant() and isconstant() being some dynamic
>implementation to mark objects with certain information
>(using e.g. weak reference dictionaries). The optimizer could
>then recognize the assert statements and use the included
>information to e.g. preload globals. Non-optimized code
>would perform the check for means of debugging.

I'm not so keen on something like this - assert is standard, but
custom marking like this tends to restrict portability.  I guess
that someone who wanted to use code like this in a module could
check for the existence of the optimizer, and if it is not present
define dummy functions so that it will at least run.  But for the
time being this is low on the priority list.

Corran