Receive data from socket stream

Nick Craig-Wood nick at craig-wood.com
Tue Apr 29 05:30:03 EDT 2008


Hrvoje Niksic <hniksic at xemacs.org> wrote:
>  Nick Craig-Wood <nick at craig-wood.com> writes:
> 
> >>  Note that appending to a string is almost never a good idea, since it
> >>  can result in quadratic allocation.
> >
> > My aim was clear exposition rather than the ultimate performance!
> 
>  That would normally be fine.  My post wasn't supposed to pick
>  performance nits, but to point out potentially quadratic behavior.
> 
> > Anyway str += was optimised in python 2.4 or 2.5 (forget which) wasn't
> > it?
> 
>  That optimization works only in certain cases, when working with
>  uninterned strings with a reference count of 1, and then only when the
>  strings are in stored local variables, rather than in global vars or
>  in slots.  And then, it only works in CPython, not in other
>  implementations.  The optimization works by "cheating" -- breaking the
>  immutable string abstraction in the specific cases in which it is
>  provably safe to do so.
>  http://utcc.utoronto.ca/~cks/space/blog/python/ExaminingStringConcatOpt
>  examines it in some detail.

Ah, I didn't realise that - thanks for the interesting link.

For the example I gave, just a simple local variable the optimisation
kicks in.  I can see how you could easily migrate that to an instance
variable and the optimisation would no longer work, eg

$ python -m timeit -s 's=""' 'for i in xrange(10000): s+="x"'
1000 loops, best of 3: 1.04 msec per loop

$ python -m timeit -s 'class A: pass' -s 'a=A(); a.s=""' 'for i in xrange(10000): a.s+="x"'
10 loops, best of 3: 160 msec per loop

>  Guido was reluctant to accept the patch that implements the
>  optimization because he thought it would "change the way people write
>  code", a sentiment expressed in
>  http://mail.python.org/pipermail/python-dev/2004-August/046702.html
>  This discussion shows that he was quite right in retrospect.  (I'm not
>  saying that the optimization is a bad thing, just that it is changing
>  the "recommended" way of writing Python in a way that other
>  implementations cannot follow.)

Certainly something I wasn't aware of before - thanks!

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick



More information about the Python-list mailing list