REGRESSION(r103608): div.lang is 4.8x slower than div.title

[Kentaro Hara]

Performance regression. div.lang and div.title should pass almost exactly the same call path, but div.lang is 4.8x slower than div.title. This performance degradation are also happening on other DOM attributes.

[1] console.time("a"); for (i = 0; i < 1000000; i++) { div.title = undefined } console.timeEnd("a")
[2] console.time("a"); for (i = 0; i < 1000000; i++) { div.lang = undefined } console.timeEnd("a")

Mac Safari 5.1.1 (6534.51.22) with WebKit r100463: [1] 664ms, [2] 600ms
Mac Safari 5.1.1 (6534.51.22) with WebKit r105123: [1] 580ms, [2] 2825ms

Linux Chromium 17.0.963.26 (Official Build 116225) with WebKit r103967: [1] 1385ms, [2] 1418ms
Linux Chromium 18.0.1010.0 (Developer Build 117871) with WebKit r105123: [1] 1405ms, [2] 4110ms

[Kentaro Hara]

Let me raise the priority. I am bisecting the revision that caused the regression.

[Kentaro Hara]

This regression is due to r103608 (http://trac.webkit.org/changeset/103608/trunk/Source/WebCore/html/HTMLElement.cpp).

(In reply to comment #0)
> Performance regression. div.lang and div.title should pass almost exactly the same call path, but div.lang is 4.8x slower than div.title. This performance degradation are also happening on other DOM attributes.

Sorry, this observation was wrong. Not the same call path. Some DOM attributes pass different call paths in HTMLElement::parseMappedAttribute(), and it causes the performance difference.

> div.lang is 4.8x slower than div.title

darin: I am not sure whether it is worth fixing the performance degradation. FYI, here is the profiling result of DOM attribute getters and setters. div.lang takes the longest time: https://docs.google.com/spreadsheet/ccc?pli=1&key=0Aqe43qi_L8gQdHhzOXZaRGdPVGEzUTlLMHpmRWMtVWc&hl=ja#gid=0

[Darin Adler]

Given the cause, this slows down tree building of lang attributes as well as setting the lang attribute via DOM. We could test to check that.

I think it’s worth considering speeding up the extremely common case of using lang attributes but not using locale-dependent CSS styling.

[Matt Falkenhagen]

Here's some background if it helps (information is spread over many bugs).

Before r103608 there was no way to quickly get the lang of a node, which is needed by the engine for, e.g., font selection.

There had been other proposals for fast access to lang. Adding lang to RenderStyle was once attempted, but ran into difficulties (bug 9454 comments 23-36).

Caching the computed lang in something like rare data also looks difficult because of the invalidation cost when the value changes (bug 21312 comment 5)

So, the approach of mapping lang to the CSS property was taken (bug 10874 comment 22 and bug 16801 comment 8). If it's too slow, perhaps we can relook at the RenderStyle approach?

[Kentaro Hara]

It appears this performance regression is already fixed.

Test1: (function () { var div = document.createElement("div"); console.time(1); for (var i = 0; i < 100000000; i++) { div.lang } console.timeEnd(1); })();

Test2: (function () { var div = document.createElement("div"); console.time(1); for (var i = 0; i < 100000000; i++) { div.title } console.timeEnd(1); })();


Results:

Test1 on Chromium/Mac: 2534ms
Test2 on Chromium/Mac: 2531ms
Test1 on AppleWebKit/Mac: 1277ms
Test2 on AppleWebKit/Mac: 1278ms