[summerofcode] High-level python optimizer.

[Skip Montanaro]

    Vladimir> 2. Function inlining (which can be significant in python) can be
    Vladimir>    done if we know what function is being called. For method
    Vladimir>    inlining we must know the type of the object and check
    Vladimir>    __getitem__ for side-effects.

It's not that easy.  attribute names (including method names) can be rebound
on-the-fly, and you may not be able to detect it ahead of time.  In
addition, the rebinding can happen from action at a distance (one module
messing with the elements of another).

    Vladimir> 4. Dead code elimination can be done as part of parial
    Vladimir>    evaluation....

But does speed anything up.  At best, it might help you identify other
blocks of code that be coalesced.

    Vladimir> 5. Common subexpression elimination (as well as moving common code
    Vladimir>    outside loops) can be done if subexpression has no
    Vladimir>    side-effects. This is even more actual in python than in
    Vladimir>    static-typed languages because the code

    Vladimir> the.some.method(x)
    Vladimir> the.some.method(y)
    Vladimir> or
    Vladimir> for x in some_big_list: the.some.method(x)

    Vladimir> is very common. the.__getitem__("some").__getitem__("method") is
    Vladimir> the common code.

You mean getattr(the, "some") here I think.

    Vladimir> 6. There are also some python-specific optimization, for example
    Vladimir>    replacing range with xrange when possible, replacing the code
    Vladimir> (a,b)=(b,a)
    Vladimir> with the code
    Vladimir> t=a; a=b; b=t
    Vladimir> and so on.

Been there.  Done that.  Only modest improvements result.

    Vladimir> All of this is high-level optimization, it should be used on top
    Vladimir> of the low-level optimizations. 

If tuple unpacking elimination is high-level, what do you mean by low-level?

Skip