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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4