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