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.