On 2011-08-25, at 18:58 , Antoine Pitrou wrote:
Le jeudi 25 août 2011 à 18:50 +0200, Masklinn a écrit :
On 2011-08-25, at 18:40 , Antoine Pitrou wrote:
The most popular (as from what I can see) thing right now where people start seeing that += is slow is when they try to do that on PyPy (which doesn't have hack like CPython, who is still slow) and ask "why my pypy code is sooooo slow".
Different implementations having different performance characteristics is not totally unexpected, is it? (and I'm sure the PyPy developers wouldn't mind adding another hack) This one can not be done, as it relies on knowing there's only one reference to the string (so it can be realloc'd in place), therefore on using a refcounting GC. Ah, you're right. However, PyPy has another (and quite broader) set of optimizations available: http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html#strin... Yeah but none of them has reached enough utility to be the default pypy state, so it's not like it's a good idea to rely on them (it's nice to know these options exist as they can be nice in a per-case basis though).
Besides:
Since Pypy does not use refcounting, it can't do that as a rule (it might be possible to handle it for a limited number of cases via escape analysis, proving there can be only one reference to the string, but I'd say there are more interesting things to use escape analysis for).
The CPython optimization itself works in a limited number of cases, because having a refcount of 1 essentially means it's a local variable, and because of the result having to be stored back immediately in the same local variable (otherwise you can't recycle the original object's storage). True, I realized afterwards I should probably have written "a likely even more limited number of cases than CPython". Oh well.