diff options
Diffstat (limited to 'Source/WebCore/ChangeLog')
| -rw-r--r-- | Source/WebCore/ChangeLog | 148 |
1 files changed, 148 insertions, 0 deletions
diff --git a/Source/WebCore/ChangeLog b/Source/WebCore/ChangeLog index 42d6cd1..c877435 100644 --- a/Source/WebCore/ChangeLog +++ b/Source/WebCore/ChangeLog @@ -1,3 +1,151 @@ +2012-03-16 Kentaro Hara <haraken@chromium.org> + + [Performance] Optimize innerHTML and outerHTML + https://bugs.webkit.org/show_bug.cgi?id=81214 + + Reviewed by Adam Barth. + + This patch makes innerHTML and outerHTML 2.4 times faster. + + Performance test: https://bugs.webkit.org/attachment.cgi?id=132034 + The performance test measures body.innerHTML for 3000 lines of HTML, + which is copied from the HTML spec. + + - Chromium/Mac without the patch + div.innerHTML: 1658.6 ms + div.outerHTML: 4859.6 ms + body.innerHTML: 640.2 ms + body.outerHTML: 641.8 ms + + - Chromium/Mac with the patch + div.innerHTML: 751.0 ms + div.outerHTML: 2096.0 ms + body.innerHTML: 271.2 ms + body.outerHTML: 271.2 ms + + - Chromium/Linux without the patch + div.innerHTML: 950.4 ms + div.outerHTML: 2257.8 ms + body.innerHTML: 452.8 ms + body.outerHTML: 457.6 ms + + - Chromium/Linux with the patch + div.innerHTML: 582.4 ms + div.outerHTML: 1283.0 ms + body.innerHTML: 233.0 ms + body.outerHTML: 233.4 ms + + - AppleWebKit/Mac without the patch + div.innerHTML: 900.6 ms + div.outerHTML: 2245.2 ms + body.innerHTML: 462.6 ms + body.outerHTML: 468.0 ms + + - AppleWebKit/Mac with the patch + div.innerHTML: 529.8 ms + div.outerHTML: 1090.2 ms + body.innerHTML: 239.2 ms + body.outerHTML: 239.2 ms + + This patch applies the following two optimizations: + + (a) Remove redundant copies between Vector<String> and StringBuilders + in MarkupAccumulator::serializeNodes(), MarkupAccumulator::appendStartTag(), + and MarkupAccumulator::appendEndTag(). + + (Previous behavior) + - Create a StringBuilder for each tag. + - Append a created string in each StringBuilder to Vector<String>, + parsing the DOM tree. + - After the parsing, allocate a StringBuilder whose size is the sum + of all Strings in Vector<String>. + - Append all Strings in Vector<String> to the StringBuilder. + (New behavior) + - Allocate a StringBuilder with a default buffer size. + - Append created strings to the StringBuilder, incrementally parsing + the DOM tree. + + (b) Optimize stringBuilder.append(). + (b-1) Replace stringBuilder.append("A") with stringBuilder.append('A'). + stringBuilder.append("A") requires to cast the characters to LChar*, + and then call strlen("A"). stringBuilder.append('A') is faster. + (b-2) Replace stringBuilder.append("AB") with stringBuilder.append('A') + and stringBuilder.append('B'). In my experiment, appending characters + one by one is faster than appending the characters at a breath if the + number of characters is less than 3. + (b-3) Hard-code a string length; i.e. replace stringBuilder.append("ABCDE") + with stringBuilder.append("ABCDE", 5). While the former requires to call + strlen("ABCDE"), the latter does not. + + (a) improves performance by 170% ~ 200%. (b) improves performance by 30 ~ 40%. + + Tests: fast/dom/Range/range-extract-contents.html + fast/dom/serialize-nodes.xhtml + fast/dom/XMLSerializer.html + and all other tests that use innerHTML or outerHTML. + No change in the test results. + + * editing/MarkupAccumulator.cpp: + (WebCore::MarkupAccumulator::serializeNodes): + (WebCore::MarkupAccumulator::appendString): + (WebCore::MarkupAccumulator::appendStartTag): + (WebCore::MarkupAccumulator::appendEndTag): + (WebCore::MarkupAccumulator::concatenateMarkup): + (WebCore::MarkupAccumulator::appendQuotedURLAttributeValue): + (WebCore::MarkupAccumulator::appendComment): + (WebCore::MarkupAccumulator::appendDocumentType): + (WebCore::MarkupAccumulator::appendProcessingInstruction): + (WebCore::MarkupAccumulator::appendOpenTag): + (WebCore::MarkupAccumulator::appendAttribute): + (WebCore::MarkupAccumulator::appendCDATASection): + * editing/MarkupAccumulator.h: + (MarkupAccumulator): + +2012-06-27 Kentaro Hara <haraken@chromium.org> + + Performance: Optimize Dromaeo/dom-query.html by caching NodeRareData on Document + https://bugs.webkit.org/show_bug.cgi?id=90059 + + Reviewed by Ryosuke Niwa. + + This patch improves performance of document.getElementsBy*(). + e.g. the patch makes Dromaeo/dom-query.html 5.4% faster. + + Dromaeo/dom-query.html without the patch (Chromium/Linux): + 784714 runs/s, 765947 runs/s, 803109 runs/s, 804450 runs/s + + Dromaeo/dom-query.html with the patch (Chromium/Linux): + 839245 runs/s, 829867 runs/s, 811032 runs/s, 847486 runs/s + + Based on the assumption that document.getElementsByClassName(), + document.getElementsByTagName() and document.getElementsByName() + would be used frequently in the real world, this patch implements + a fast path for Document methods that require to access NodeRareData. + Specifically, this patch caches a pointer to NodeRareData on Document, + by which Document can access NodeRareData without looking up a HashMap. + + The only performance concern is the overhead of the isDocumentNode() check + that this patch added to Node::ensureRareData. However, I could not + observe any performance regression caused by the overhead. + + No tests. No change in behavior. + + * dom/Document.cpp: + (WebCore::Document::Document): + (WebCore::Document::setCachedRareData): I didn't inline this method, + since the inlining slightly regressed performance for some reason. + (WebCore): + * dom/Document.h: + (WebCore): + (WebCore::Document::cachedRareData): + (Document): + (~Document): Moved 'm_document = 0' to the tail of the destructor, + since isDocumentNode() has to return true in clearRareData() that is called + in ~Document(). + * dom/Node.cpp: + (WebCore::Node::ensureRareData): + (~Node): Moved the assertion into clearRareData(). + 2012-04-09 James Robinson <jamesr@chromium.org> Remove partially implemented per-Element visibility checks from requestAnimationFrame logic |