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