Ryszard Szopa <[EMAIL PROTECTED]> writes: >> The main determinant of Python's performance isn't the interpreter >> overhead, but the amount of work that must be done at run-time and >> cannot be moved to compile-time or optimized away. > > Well, I am still not convinced that Python is intrinsically > un-compilable :-).
It's not. My point is that it's very hard to optimize if your goal is to implement Python as currently defined. > Some optimizations that are nowadays done by hand probably could be > abstracted. Think assigning a method to a local variable before using > it in a loop... That's an example of what I'm talking about: it is simply not correct to cache methods in general. If you think changing classes is a no-no, remember that function objects can be and do get added to an individual instance's __dict__. Of course, your compiler could support a declaration that disables the optimization for code that really needs to do it, but then you're no longer compatible with Python. (And by "Python" I don't mean just CPython, but the core language as defined by the language reference and implemented in CPython, Jython, and IronPython.) > Anyway, I won't be very surprised if in a couple of years your > average c.l.py troll is going to be asking "So I heard that Python > is an interpreted only language, how can it be any good?", and you > will be explaining for the thousandth time: "Since version 4.2 > Python has a fast native code compiler, so...". ;-) I'll be very happy to be proven wrong in that respect. :-) -- http://mail.python.org/mailman/listinfo/python-list
