Simple question about how the optimizer works

James J. Besemer jb at cascade-sys.com
Fri May 10 04:43:22 EDT 2002


Robin Becker wrote:

> In article <mailman.1021010718.12133.python-list at python.org>, James J.
> Besemer <jb at cascade-sys.com> writes
> .....
> >
> >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.
> >
> .....
> Well strictly speaking this is untrue. This class of optimisation is
> called 'local', 'greedy' or perhaps 'peephole'. Since in fact they may
> not be optimal these methods are really improvers. As to whether most
> optimisers are like this I suppose all the compiler builders who claim
> 'global' etc etc may want to dispute.

No, I was using "pattern" in it's most general sense, meaning to include both
global and local optimizers.  In this overall thread I have alluded to examples in
both extremes.

Global optimizers typically examine the attributed parse tree for an entire module
(multiple variable and function declarations), searching for arbitrarily complex
"patterns" in the overall tree.  When there's a "match," an arbitrarily complex
transformation may be applied to the tree.  Analysis can can include determining
data flows and control flows, necssary to handle some of the tricky things even in
dynamic languages.  It also leads to better diagnostics, such as the detection of
uninitialized variables, unreachable code, etc.

This contrasts with so-called "peep hole" optimizers.  Peepholes typically look at
the outgoing code and look for low-level patterns that can be replaced by more
efficient machine code idioms.

I suppose one could argue that any so-called 'optimizer' is merely an 'improver'.
Generally there are limit cases that can confound just about any attempts at
optimization.

Finally, I will defer to Mr. Dalke's assertion that optimization has been
thoroughly explored for Python and deemed to be more trouble than it's worth, at
least compared to other priorities.

Regards

--jb


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







More information about the Python-list mailing list