<div class="gmail_quote">On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler <span dir="ltr"><<a href="mailto:darin@apple.com">darin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi folks.<br>
<br>
The key to fast use of WTF::String is to avoid creating temporary WTF::StringImpl objects or temporary copies of string data.<br>
<br>
With the latest enhancements to WTF::String, here are the preferred fast ways to build a new string:<br>
<br>
 † †- A single expression with the + operator and arguments of type WTF::String, char, UChar, const char*, const UChar*, Vector<char>, and WTF::AtomicString.<br>
 † †- A call to the WTF::makeString function.<br>
 † †- An expression that uses a single function on the string, or uses the + operator exactly once, or the += operator with the types it supports directly.<br>
 † †- WTF::StringBuilder, in cases where the logic to compute the pieces of the string has complex branching logic or requires a loop.<br>
<br>
Here are acceptable, but not preferred ways to build a new string:<br>
<br>
 † †- Building up a Vector<UChar> followed by WTF::String::adopt. I believe StringBuilder is always better, so we should probably retire this idiom.<br>
<br>
Inefficient ways to build a new string include any uses of more than one of the following:<br>
<br>
 † †- WTF::String::append.<br>
 † †- The += operator.<br>
<br>
There are other operations that modify the WTF::String; none of those are efficient if the string in question is then modified further.<br>
<br>
 † †- WTF::String::insert.<br>
 † †- WTF::String::replace.<br>
<br>
In addition, there are quite a few operations that return a WTF::String, and none of those are efficient if the string in question is then modified further.<br>
<br>
 † †- WTF::String::number.<br>
 † †- WTF::String::substring.<br>
 † †- WTF::String::left.<br>
 † †- WTF::String::right.<br>
 † †- WTF::String::lower.<br>
 † †- WTF::String::upper.<br>
 † †- WTF::String::stripWhiteSpace.<br>
 † †- WTF::String::simplifyWhiteSpace.<br>
 † †- WTF::String::removeCharacters.<br>
 † †- WTF::String::foldCase.<br>
 † †- WTF::String::format.<br>
 † †- WTF::String::fromUTF8.<br>
<br>
One reason I bring this up is that if we wanted to make combinations of these more efficient, we might be able to use techniques similar to those used in StringOperators.h to make it so the entire result string is built at one time, eliminating unnecessary copies of the string characters and intermediate StringImpl objects on the heap.<br>

<br>
It would be interesting to find out how often the inefficient idioms are used. Until recently, there was no significantly better alternative to the inefficient idioms, so itís highly likely we have them in multiple places.<br>

<br>
A quick grep showed me inefficient uses of += in XMLDocumentParser::handleError and XPath::FunTranslate::evaluate, parseRFC822HeaderFields, InspectorStyleSheet::addRule, drawElementTitle in DOMNodeHighlighter.cpp, WebKitCSSTransformValue::cssText, CSSSelector::selectorText, CSSPrimitiveValue::cssText, CSSBorderImageValue::cssText, and CSSParser::createKeyframeRule.<br>

<br>
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.<br>
<br>
Iím looking for two related things:<br>
<br>
 † †1) A clean way to find and root out uses of the inefficient idioms that we can work on together as a team.<br>
<br>
 † † 2) Some ways to further refine WTF::String so itís harder to ďuse it wrongĒ. I donít have any immediate steps in mind, but one possibility would be to remove functions that are usually part of poorly-performing idioms, pushing WebKit programmers subtly in the direction of operations that donít build intermediate strings.<br>

<br>
 † †-- Darin<br><br></blockquote><div><br></div><div><br></div><div>This thread resonates very deeply with me (idioms that make it hard to write slow code == pure goodness), but I suspect we really ought to build performance tests to help support these improvements. †It is easy to put a lot of energy into optimizing code that provides no measurable benefit :-/</div>
<div><br></div><div>-Darin</div></div><br>