Simple question about how the optimizer works

[James J. Besemer]

Andrew Dalke wrote:

[many examples of increasingly well hidden side-effects]

Granted. There are a lot of ways to break the optimization, some fairly
insidious.

> Unless the compiler could look (somehow!) into the definition of each
> __nonzero__, or disable optimizations if _getframe(), sys.exc_info(), etc.
> are used *anywhere* in the Python code, then there's no way it can build
> that optimization.

True.  And this is exactly what the best optimizers do.  Look at all the
relevant code.

The way most optimizers work is they detect patterns known to be safe and also
sufficiently common to be worth dealing with.  Anything that does not fit the
pattern 100% does not get optimized.

In practice, the function in question often is defined in the same source module
as where it is used.  In most examples of list comprehensions, everything is
spelled out within the comprehension itself, as simple expressions of primitive
objects.

The other possibility someone else raised was that we could allow the programmer
to declare what functions may be safely optimized, though it would admit the
risk of very strange errors when the programmer is mistaken.

Recognizing just a few of the most common cases might make a significant
difference.  I understand Perl does this for certain common top-level loop
constructs, in order to realize significant gains for those cases.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com