[webkit-dev] Slow idioms with WTF::String

Ryosuke Niwa rniwa at webkit.org
Tue Jul 12 10:52:08 PDT 2011

Excited to see WTF::String getting easier to use efficiently!

On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler <darin at apple.com> wrote:
> I would not be surprised if at least some of these will show up immediately
> with the right kind of performance test. The CSS parsing and serialization
> functions seem almost certain to be measurably slow.

Yes indeed.  Serialization code is very inefficient now.

On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler <darin at apple.com> wrote:
> Here are acceptable, but not preferred ways to build a new string:
>    - Building up a Vector<UChar> followed by WTF::String::adopt. I believe
> StringBuilder is always better, so we should probably retire this idiom.
> Inefficient ways to build a new string include any uses of more than one of
> the following:
>    - WTF::String::append.
>    - The += operator.

MarkupAccumulator and StyledMarkupAccumulator do exactly this.

MarkupAccumulator have many appendX member functions where X is the name of
a node type.  When one of those functions is called, it'll create a
Vector<UChar> which is passed around helper functions to build up the
serialization for the node.  The Vector<UChar> is then adopted as String and
put into a Vector<String>.   The resultant vector is aggregated as one giant
String at the end.

It seems like the solution here is to use StringBuilder?

StyledMarkupAccumulator is somewhat tricker to make efficient because it'll
reverse the order of Strings in Vector<String> when aggregating the vector.
 Since we wouldn't know the last String (the first substring to appear in
the final serialization) at the beginning, we can't use StringBuilder.

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110712/63e5f350/attachment.html>

More information about the webkit-dev mailing list