[Webkit-unassigned] [Bug 17510] Acid3 pauses noticeably while running test 26

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=17510


darin at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at webkit.org,
                   |                            |mjs at apple.com




------- Comment #7 from darin at apple.com  2008-03-17 14:28 PDT -------
I started looking at the profile. There's no one huge item here--a lot of stuff
is pretty fundamental--but there are various things we could improve. One
recurring area seems to be conversions from numbers to strings and from WebCore
strings to JavaScriptCore strings.

In this profile:

    - The top item on the list is 4.3% in KJS::Lookup::findEntry; the hash
tables we use to look up built-in properties are not working well enough; some
kind of single element cache might save the day, or we could come up with a
more efficient technique for this.

    - We are spending 2.7% of the time in UString::from(double), converting the
loop count into a string so it can be appended to another string to create a
text node.

    - We are spending 2.3% of the time in StringImpl::create, allocating new
WebCore::String objects. If you include ~StringImpl (and we should), then it's
3.4%. Most of this time, 1.8%, is in JSHTMLDocument::canGetItemsForName. We
should change this code path so it doesn't involve allocating a String. But
also 0.2% for setAttribute and 0.2% for getElementById and 0.1% for
createTextNode.

    - 1.2% of the time is in Document::isValidName. We've got to be able to do
that one faster!

    - 1.1% of the time is in JSHTMLDocument::canGetItemsForName, not counting
the string creation. We've got to be able to do that one faster!

    - 1.1% of the time is spent in getDOMNodeForDocument, finding wrappers for
the DOM nodes. Two hash table lookups every time. Maybe we should abandon the
purity of it and put wrapper pointers into DOM::Node?

    - 1.1% of the time is in the GC allocator.

    - 1.1% of the time is in parseClassAttribute, which has to fold case and
break up an arbitrary string into a list of class names. Maybe we could defer
that parsing until style resolution time? Or add a fast case for when all the
letters are non-upper-case ASCII.

    - 0.9% of the time is spent changing a char* into an AtomicString in
JHTMLAnchorElementPrototype::self and JSTextPrototoype::self. Seems fixable.

    - 0.8% of the time is spent concatenating UString objects; because of the
createTextNode and the assert in this function, it's a stress test of string
appending.

    - We are spending 0.7% of our time in Document::isValidName checking the
string "class" to see if it's a valid name, in an expensive ICU
u_getIntPropertyValue call.

    - 0.7% is spent just in JSObject::type.

    - 0.5% of the time is spent changing an ID into an AtomicString in
getElementById. And an additional 0.3% each is spent in setAttribute and
createElement doing the same thing. Since these are the same short ASCII
strings over and over again we should think about how to do it faster.

    - 0.3% of the time is converting a DOM string to a JavaScript string in
JSCharacterData::getValueProperty; presumably this is the ".data" call in the
assert.

There's also some more of the pure JavaScript interpreter overhead, looking up
properties and such.

It's costing us performance that all calls to toJS are going through
EventTarget* first and only then going on to Node*. We need to change the Node*
one from PassRefPtr to Node* and then eliminate all the ambiguity. We want
calls to all go straight to the Node* version!


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.