[Python-ideas] Create a StringBuilder class and use it everywhere

Masklinn masklinn at masklinn.net
Thu Aug 25 19:35:39 CEST 2011


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#string-optimizations
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.


More information about the Python-ideas mailing list