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 dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo