First synchronous hammering performance numbers

[Josh Matthews]

The following script (test_hammer_layout.html) can now run in Servo, so
I've finally been able to begin obtaining baseline performance data.
Note that this is with the exiting Rust scheduler, not Brian's new one:

>var divs = document.getElementsByTagName("div");
>var div = divs[0];
>
>var count = 1000000;
>var start = new Date();
>for (var i = 0; i < count; i++) {
> div.setAttribute('id', 'styled');
> div.getBoundingClientRect();
>}
>var stop = new Date();
>window.alert((stop - start) / count * 1e6);
>window.close();

This yields 1239493.

Cheers,
Josh

[Josh Matthews]

For the sake of contrast, a current Firefox nightly shows me 1319.

[Josh Matthews]

And interestingly enough, the same test with the
div.getBoundingClientRect call removed yields a marginally better 1162253.

[Patrick Walton]

So I guess the problem is that setAttribute() is slow?

Josh Matthews <jo...@joshmatthews.net> wrote:

>On 05/27/2013 03:45 PM, Josh Matthews wrote:

>And interestingly enough, the same test with the
>div.getBoundingClientRect call removed yields a marginally better
>1162253.

>_______________________________________________
>dev-servo mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-servo

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[Josh Matthews]

That appears to be the wrong conclusion; when I remove the code that
triggers the reflow from set_attr, the number drops by two orders of
magnitude. The layout task appears to be eating into the script task's
performance.

[Robert O'Callahan]

I'm pretty sure that Gecko short-circuits setting of an attribute to the
value it already has, in the DOM code. So this may not be testing what you
want.

Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

[Boris Zbarsky]

On 5/27/13 2:25 PM, Josh Matthews wrote:
> The following script (test_hammer_layout.html) can now run in Servo

> This yields 1239493.

That's nanoseconds per iteration. As in, 1.2ms (!). This is not really
ok. ;)

Is this with builds that do the "eagerly kick off layout from any DOM
change" bit? I really do think that we should not be doing that: people
batch up lots of DOM changes together, so doing layout from every change
is almost certainly not useful...

-Boris

[Boris Zbarsky]

On 5/27/13 9:19 PM, Robert O'Callahan wrote:
> I'm pretty sure that Gecko short-circuits setting of an attribute to the
> value it already has, in the DOM code.

And the spec requires that behavior, fwiw, in various ways.

-Boris

[Josh Matthews]

I agree completely. We'll need to spend some time figuring out what kind
of batching behaviour we want, but the test right now has been useful to
expose what seems to be an architectural problem, possibly due to the
current scheduler. My investigation in
https://github.com/mozilla/servo/issues/487 digs into this, and I'm keen
to try the same test on top of Brian's work now.