Speeding up: s += "string"

Jp Calderone exarkun at intarweb.us
Tue Apr 15 13:26:58 EDT 2003


On Tue, Apr 15, 2003 at 08:29:35AM -0600, sik0fewl wrote:
> Cameron Laird wrote:
> >I'm not optimistic.  I'll be more precise:  the problem
> >is real, and good solutions are sensitive to data char-
> >acteristics.  It's easy to improve performance of the
> >s1 += s2 operations that characterize e-mail filtering
> >while simultaneously degrading unacceptably the same
> >operation embedded in an XML filter.  I am close to
> >asserting the conjecture that every solution harms too
> >many existing legitimate users.
> 
> Just adding my two cents..
> 
> People should keep in mind that s += a is shorthand for s = s + a. If you 
> look at it the second way you can clearly see that a is appending to s and 
> then s is *assigned* that value. In both cases two operations are being 
> done.
> 

  While your first point is correct (but *only* for immutable s), I don't
see how it matters that there are two operations being performed.

  Binding a name is practically free.  It's an extra trip through the
interpreter loop, yes, but those are pretty fast.  The opcode isn't called
STORE_FAST for nothing ;)

> Perhaps we could introduce .= as a true assign/append operation. Although 
> this would still be a mutable operation, which contradicts the documents.

  And would hence require a new string type.  I somewhat like Alex's idea of
wrapping std::rope.  I've never had a practical use for it myself, but I've
always *wanted* to, because it's such a nice approach :)

  Jp

-- 
No, `Eureka' is Greek for `This bath is too hot.'
                -- Dr. Who
-- 
 up 26 days, 13:02, 2 users, load average: 0.00, 0.02, 0.04





More information about the Python-list mailing list