RE: [Python-Dev] Thoughts on -O

One I had in mind would be the CALL_ATTR patch, which Guido explicitly mentioned as having been implemented on the main path, not on the optimised path, and pointed out that if it had been implemented only on the optimised path a number of issues with it would have been discovered much earlier.
The only one that makes any appreciable difference is Psyco
Indeed. I would love Psyco to eventually be part of Python, but suspect it will only be so in the PyPy implementation.
Many of the recent optimisation patches have involved 5% speedups in some cases. If they all worked without impacting each other (cache effects, etc) we could probably approach 50% improvement in some cases. I have no problems if someone can get a 5% speedup across the board without introducing incredibly hairy code. I would like such optimisations to eventually become part of the main path - but I would prefer that it not become part of the main path until it has been exposed to many different environments - assuming the implementor or someone else can't come up with one or more cases where it becomes a pessimisation.
Indeed. Every attempt so far has either been in the 5% improvement or less, standalone, and most have resulted in worse performance when combined. Tim Delaney

[Tim Delaney]
Correction: I meant to say that about the optimization of expressions of the form '-' NUMBER # e.g. -1 This was buggy for years. I'm not aware of problems with CALL_ATTR (which exists only as a patch on SF) except that it's not always a speedup. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

[Tim Delaney]
Correction: I meant to say that about the optimization of expressions of the form '-' NUMBER # e.g. -1 This was buggy for years. I'm not aware of problems with CALL_ATTR (which exists only as a patch on SF) except that it's not always a speedup. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Delaney, Timothy C (Timothy)
-
Guido van Rossum