[Webkit-unassigned] [Bug 17510] Acid3 test 26 takes >33ms

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun May 25 12:34:44 PDT 2008


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





------- Comment #32 from darin at apple.com  2008-05-25 12:34 PDT -------
(In reply to comment #26)
> 5) 0.7% in Node::isReadOnlyNode().

I have a patch that cuts this down to about 0.1% attached to the related bug.
(I noticed unnecessary multiple calls to nodeType() in
Node::appendTextContent.)

Other optimization thoughts (not the kind of great ideas Maciej posted, but
still perhaps useful):

A) 1.5% of the time is taken converting the string "class" from a UString to an
AtomicString. If we could find some way to not search the hash table over and
over again here, that'd be a big win.

B) DOM getOwnPropertySlot functions are taking a lot of time, more than 5%. The
big costs are the PIC branch used to get access to the global table and the
memory accesses in that table. And the size for the hash table for JSDOMNode,
for example, is huge -- 4096 slots for the 19 values just to avoid the need to
rehash. Maybe there's a better data structure we can use?

C) Overhead for render objects we never end up rendering is still a big part of
the profile, even with Maciej's tear-down optimization. For example,
CSSStyleSelector::styleForElement is 4.7% of the time and the total time for
createRendererIfNeeded is 12.5%. And this is all for an element that's going to
be removed before the next layout. If we can find a way to defer creating the
renderer and never end up doing it at all then we will get a *big* speedup.
Maybe we can change things so that renderers can be created at layout time.

D) Tons of time is spent inside toJS, making wrappers for the text node and
HTMLAnchorElement objects that are created and looking for the existing wrapper
for the result of parentNode, nextSibling, and others. We could cut down a lot
of hash table overhead if we were willing to put a pointer in every
WebCore::Node to the corresponding JSNode

E) We could avoid making a lot of JS string wrappers if we could create code
paths that would keep the UString in the engine register until the value needs
to be used as a generic value. The expression "iteration " + i + " failed"
results in creation of many string wrappers and it's never used for anything at
all. Similarly, the expression "iteration " + i + " at " + d results in the
creation of many string wrappers and ultimately it's passed to createTextNode,
which takes a string parameter rather than an arbitrary object value. I suspect
that we could speed up by more than 5% by reducing the number of string
wrappers if we could get the strings to the "+" operator and to the function
call without converting to a wrapper, but that's probably a tall order.

F) The StringImp::toString function, 0.5%, would benefit from
omit-frame-pointer.

G) The defaultValue function doesn't need to be a virtual function. Right now
the bridge is using a custom implementation of defaultValue, but that's not
really helpful. In fact, some of the overrides are actually using the wrong
function signature (including ExecState*)! On the other hand, what's really
slow here is all the overhead for doing a function call, and that's probably
due to the crazy toString/defaultValue test case that's in test 26, so it might
not be easy to optimize.

H) 0.6% of the time is in Document::body(). We can easily add code so that's
cached.

I) We spend considerable time repeatedly checking if "class" is a valid name.
Maybe we can cache that. We also pay function overhead to get the length and
characters pointer from a String object. Those should probably be inlined.

J) Frame::page() is 0.3% -- we should probably move the page pointer from the
private pointer to the top level of the Frame object and then inline the
getter.

K) Inside the code to implement new Date we spend a lot of time in the floor
inside getCurrentUTCTime. This could be avoided by dividing changing that code
path tv_usec by 1000 as an integer operation instead of a floating point one.
That's only 0.1% though.

L) NumberImp::toObject is taking 0.7% of the time. That's all being done to
call toString() on the value of the date. Is there a way to avoid the toObject
in that op_get_by_id opcode when it's a built-in function on Number? We already
have to branch to convert to an object, but we could use that branch to instead
go to a special version of the get operation for the non-object JavaScript
types that avoids creating an object. Seems like it could be a 1% speedup.

M) documentBeingDestroyed() is showing up as 0.2% on the profile. It's simple
and can be inlined.

N) It looks like the empty case of ~PropertyMap should be inlined. The 0.2%
time spent in that function seems to all in that empty case.

O) numerProtoFuncToString could be changed around so that the "no radix passed"
case is slightly faster for up to a 0.3% speedup.


-- 
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.



More information about the webkit-unassigned mailing list