[Python-Dev] Wild Idea for the Year
Armin Rigo
arigo at tunes.org
Mon Jun 28 05:19:32 EDT 2004
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
More information about the Python-Dev
mailing list