On 6/7/13 9:43 AM, Benjamin Smedberg wrote:
I would love to have been invited to this meeting. Was it announced
anywhere?
It sort of grew out of an IRC conversation over the course of 20 mins or
so. :(
* Gecko has mutable strings and this is bad for performance
I'd like to understand/challenge this statement. Is this bad for
performance because you have to check the extra SHARED flag on write?
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...
I love the sentiments here, and I share our frustration with complicated
systems. But pretty much all of our string hacks, including JS dependent
strings and XPCOM dependent/literal strings exist because they solved
very noticeable performance problems. JS ropes were added in bug 571549,
for example, which is definitely not ancient history. It's worth
exploring whether we can remove that need by simplifying the string
classes, but I'm very wary of generic advice to "stay as simple as
possible" when we have prior history which indicates that simple doesn't
perform well.
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.
Was there discussion about whether string buffers should be refcounted
or GCed
There wasn't, no. It's an interesting question. There has been talk
over on the JS side to allow refcounting their strings, which would also
be very interesting since it would allow the rendering engine to share
their buffers.... as long as the encoding agrees.
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
