Hi servo-dev!
Servo exists to validate the idea that parallel browser architectures work.
Going parallel isn't always a good thing, and can sometimes be worse if there's
too much communication overhead. For example, in the current Servo design,
javascript is run in a different task than layout. This is great, but it means
that javascript calls that require communication between the tasks can incur a
lot of overhead.
Consider this HTML/JS:
<html>
<script>
var ready = function() {
var ident = document.getElementById("some_div");
var left_sum = 0;
var top_sum = 0;
var right_sum = 0;
var bottom_sum = 0;
var t0 = +new Date();
for(var i = 0; i < 10000000; i++) {
var rect = ident.getBoundingClientRect();
left_sum += rect.left;
top_sum += rect.top;
right_sum += rect.right;
bottom_sum += rect.bottom;
}
var t1 = +new Date();
ident.appendChild(document.createTextNode("sums: (" + left_sum + ", " + top_sum
+ ", " + right_sum + ", " + bottom_sum + ") "));
ident.appendChild(document.createTextNode("dt: " + (t1 - t0) + " ms"));
}
//document.addEventListener("DOMContentLoaded", ready, false)
window.onload = ready;
</script>
<body>
<div id="some_div">Working...</div>
</body>
</html>
Running this on Firefox takes 500 ns/iteration. Chrome takes 700 ns/iteration.
Servo before [1] lands took 8100 ns! That's paying a lot (some would say too
much) for a parallel architecture, when simple queries experience a 10x
slowdown.
However, thanks to [1], Servo is down to 950 ns/iteration. This is very
competitive with Firefox and Chrome, especially when considering the mutex
involved. I'm sure with some micro-optimization work we can get closer.
Because of these results, I believe that communication overhead between script
and layout can be (and has been) reduced to a competitive amount, while still
maintaining the benefits of parallelization.
Regards,
- Clark
[1] https://github.com/servo/servo/pull/3164
_______________________________________________
dev-servo mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-servo
