On 6/7/2013 11:27 AM, Boris Zbarsky wrote:
My context here is things like the code I changed in
http://hg.mozilla.org/mozilla-central/rev/e5cc69819435 which was in
theory trying to follow best practices (calling SetCapacity, etc).
But then it also did appends one character at a time and each append
had to do a bunch of "compute the new capacity and see whether we have
that much", which was fairly expensive on the scale of the overall
timing on that microbenchmark. That initial SetCapacity call actually
made things worse, not better, in common cases, by being an expensive
no-op.
Basically, every time you go to append to an nsAString it goes through
a _lot_ of code to make sure that it can end up just appending your
stuff. Maybe that's just an implementation problem with XPCOM
strings, not a general issue with mutable strings, of course.
And if you want to insert it's even more expensive. On the other
hand, inserts into an existing string, are not exactly very easy in a
stringbuilder setup...
Ah yeah, that's not a good pattern in general. Ideally mutating a string
in XPCOM should be:
* call BeginWriting with the desired length, get a buffer pointer
* manipulate that buffer pointer
* when you're done, call SetLength to the correct final length
I agree if we can get efficient stringbuilder behavior that immutable
strings are in general better, and something we should aim for.
I think the problem is that the complex thing also does not perform
well in many cases. See FakeDependentString and the DOMString struct
in Gecko which try to work around by not creating an XPCOM string at
all...
The question is whether these cases should just be special goop that
bindings do and DOM code knows about or whether the "normal" string
types can serve that need.
I wasn't aware of these; I'll follow up with you about them separately
since it may be just that our string code is doing something dumb.
--BDS
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
