[Python-Dev] Wild Idea for the Year

[Armin Rigo]

Hello Phillip,

On Sun, Jun 27, 2004 at 06:03:06PM -0400, Phillip J. Eby wrote:
> Looks interesting.  It appears the cost is added to cases that are likely 
> to have longer execution times anyway.  (i.e. the slow_add and slow_iadd 
> cases.)

Yes.  I didn't time it, but I expect that it a lot of applications would
see a small increase in performance just because special-casing + even between
small strings is faster than doing all this PyNumber_Add() madness.

> I notice that string_concatenate() doesn't cover the STORE_DEREF case, 
> however.  Was that intentional?

Ops, thanks.  I overlooked this one.

> Last question: is this actually faster when 'e' is replaced by an 
> expression that causes memory allocation?  That is, isn't this *still* 
> going to be an O(n**2) operation if the string has to be relocated on each 
> addition?

Apparently not, according to a few tests.  I suspect the memory allocator does
some kind of over-allocation automatically, though I'm not sure how much
Python's and Linux's allocators each contribute to this result.

However, I noticed that it doesn't work for expressions like s=s+t+u, because
it is associated as s=(s+t)+u.  s+=t+u works, though.


Armin