[Python-Dev] Optimized string concatenation
Guido van Rossum
guido at python.org
Tue Aug 3 17:27:26 CEST 2004
> I spent a *long* time reviewing and testing this patch. The code is
> clean. The concept works. It delivers significant, measurable
> benefits. The standard library itself has existing use cases.
> Every benchmark I tried showed results. The patch was not approved
> prematurely!
Yes it was. You know I am interested in this kind of decision
(otherwise you'd have just checked it in) so you should have left the
honor to me.
> > I am going to make up a new rule here, and state that
> > implementation features that affect not just the running speed but
> > the O() rate for certain algorithms should be considered language
> > features, because any implementation will be required to implement
> > them in order to ensure code portability.
>
> Even list.sort() does not guarantee specific O() rates. Currently,
> the fastest way to write a merge(a,b) is sort(a+b). That relies on
> the current implementation recognizing that a and b are already
> sorted and doing a linear time concatenation.
That's a much more obscure case. The string concatenation hack will
affect a significant fraction of all code.
> > Why do people want this so badly?
>
> Because the a=a+b form occurs everywhere, not just in newbie code.
> It is in the standard library, it shows up naturally in SAX, and it
> is often the most clear way to express an idea.
And in 99% of those cases nobody cares about performance.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list