RetroSearch Browse

Tue Aug 3 04:24:03 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-August/046705.html

> > * discussed on SF too is whether we should remove the 'a=a+b'
> > acceleration
> >   from the patch, keeping only 'a+=b'; see the SF tracker.

> Hmm... I couldn't think of any reason to limit the optimization
> to += until I actually went and read the comments in the SF
> tracker. What I took away from that discussion was that it's
> possible to optimize "a=a+b", but NOT possible to optimize
> "a=a+b+c". This is a subtle distinction that is harder to
> explain to people than simply saying "it only works with +=, not
> with +".
> 
> That's a fairly convincing point, so I guess I'm on the fence
> on this one.

I'm not.  Skipping a=a+b breaks symmetry with a+=b.  More importantly,
skipping a=a+b misses most of the potential benefits (see sre_parse.py
for an example).  PyBench, ParrotBench, and my other benchmarks all show
gains when a=a+b is done inplace.

The explanation is not hard.  The CPython implementation can concatenate
inplace two term expressions of the form a=a+b or a+=b.  Expressions
with more terms are not eligible for inplace concatenation.

Raymond 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/046705.html below:

[Python-Dev] Optimized string concatenation