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

[Yong Li]

How about using RopeImpl as JSString does to boost operator+=? Not
sure how bad it affects simple strings. Then another idea is to
introduce a LargeString implemented with ropes for special purposes
like parsers.

Another slow case is converting a const C string to WTF::String every
time. For example,

    return (m_httpHeaderFields.contains("If-Match") ||
            m_httpHeaderFields.contains("If-Modified-Since") ||
            m_httpHeaderFields.contains("If-None-Match") ||
            m_httpHeaderFields.contains("If-Range") ||
            m_httpHeaderFields.contains("If-Unmodified-Since"));

This function creates 5 Strings (calls fastMalloc 5 times), and also
calculates the hash key 5 times, and then throws them away.

2011/7/12 Darin Adler <darin at apple.com>:
> Hi folks.
>
> The key to fast use of WTF::String is to avoid creating temporary WTF::StringImpl objects or temporary copies of string data.
>
> With the latest enhancements to WTF::String, here are the preferred fast ways to build a new string:
>
>    - A single expression with the + operator and arguments of type WTF::String, char, UChar, const char*, const UChar*, Vector<char>, and WTF::AtomicString.
>    - A call to the WTF::makeString function.
>    - 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.
>    - WTF::StringBuilder, in cases where the logic to compute the pieces of the string has complex branching logic or requires a loop.
>
> 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.
>
> There are other operations that modify the WTF::String; none of those are efficient if the string in question is then modified further.
>
>    - WTF::String::insert.
>    - WTF::String::replace.
>
> 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.
>
>    - WTF::String::number.
>    - WTF::String::substring.
>    - WTF::String::left.
>    - WTF::String::right.
>    - WTF::String::lower.
>    - WTF::String::upper.
>    - WTF::String::stripWhiteSpace.
>    - WTF::String::simplifyWhiteSpace.
>    - WTF::String::removeCharacters.
>    - WTF::String::foldCase.
>    - WTF::String::format.
>    - WTF::String::fromUTF8.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> I’m looking for two related things:
>
>    1) A clean way to find and root out uses of the inefficient idioms that we can work on together as a team.
>
>     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.
>
>    -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>