Bytecode optimisation

[Graham Matthews]

Christian Tismer (tismer at appliedbiometrics.com) wrote:
: There is just a small socket of speed penalty for using Python.
:
: The bad thing is that when your objects become tiny and simple,
: the necssary operations become very small, and what remains
: is now the small Python socket, which is tuned into a mountain
: by that.
: 
: Therefore, I see no need to make Python faster in all cases, 
: but just in the small simple ones, where my collegues say
: "hey, nice done in Python, but why is it 50 times faster in C?"
: 
: Instead, I want Python to become as dumb as C for small
: problems, whereby keeping its wonderful flexibility for
: the rest.

My point was that I very very much doubt that you can do what you
want, namely retain Python's flexibility AND have C like performance
for the small things. Flexible semantics almost always imply poor
performance. There are some exceptions to this rule, notably Self,
but they are very rare, and tend to involve either excruiating
design care from the start (eg. Self was really designed with the
optimisations it does in mind), or a good deal of opportunism and
luck. Since Python was not designed to be fast (rather it was
designed to be flexible), you are going to have to be very very
lucky to get your C performance.

graham
-- 
             Like a bird on a wire
        Like a drunk in a midnight choir
            I have tried in my way
                  To be free