Thank you all for the enlightening inputs. I have learnt a lot just with this one question. Great to know about dis library. Ned, from explanation I now realize how important it is to do impact analysis. Things are not always rosy :).
I have always appreciated everyone over this list. This is just another opportunity. Best regards, Laxmikant On Mon, Feb 17, 2014 at 7:21 PM, Terry Reedy <tjre...@udel.edu> wrote: > On 2/17/2014 3:59 AM, Steven D'Aprano wrote: > >> On Mon, 17 Feb 2014 13:54:25 +0530, Laxmikant Chitare wrote: >> >> I read about this article: >>> http://www.python.org/workshops/1998-11/proceedings/papers/montanaro/ >>> >> montanaro.html >> >>> >>> Just wanted to clarify whether CPython already includes these kind of >>> byte code optimizations? >>> >> > Most of the easily seen and obviously safe low-hanging fruits for the > compile step have been plucked. Note that the effect of the peephole > process would only save a few percent, if any, for real apps*. Improving > the C code invoked by bytecode has resulted in much larger gains. > > * We now have a much better benchmark suite with some real apps. This is > thanks in part to the pypy project. > > > Are all the temporary variables removed when byte code is generated? >>> >> >> You can check these things for yourself: >> >> import dis >> dis.dis(function) >> >> will show you the byte code. >> >> But in general, I would expect not. CPython (that's the Python you >> probably use) doesn't do a lot of optimization apart from some simple >> constant folding. If you're interested in optimizing Python, you should >> look at the JIT optimizing Python compiler, PyPy. >> > > For CPython, new optimization has mostly moved to AST tranformations prior > to compilation. (Python ASTs are new since Skip started the peephole work.) > I believe there are some open issues on the tracker. > > Once optimization constraint Skip did not mention is the correspondence > between source lines and blocks of bytecode, which is used by profiling, > tracing, and tracebacks. Effectively transforming > > if type(a) == types.ComplexType: > x = cmath.sin(a) > foo(x) > else: > x = math.sin(a) > foo(x) > > into > > if type(a) == types.ComplexType: > x = cmath.sin(a) > else: > x = math.sin(a) > foo(x) > > breaks the correspondence. If foo(x) raises, which original line should be > reported as the source of the exception? > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list >
-- https://mail.python.org/mailman/listinfo/python-list