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

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

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

So I guess the problem is that setAttribute() is slow?
>_______________________________________________
>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.

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.

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

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

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.