[webkit-dev] A Parallel Webkit?
lmeyerov at EECS.Berkeley.EDU
Sat Jul 24 02:49:19 PDT 2010
>> JS compilation is also done lazily in webkit so we don't ever end up with multiple pieces of code to compile concurrently.
Two of us have been focusing on speeding up bottlenecks like these to allow such synchronous interfaces. However, frameworks like TBB push towards having parallel tasks that are at least 10-100,000 cycles for a good reason; working at such small scales is for people who have the luxury of targeting farther ahead and I wouldn't suggest doing it without help.
>> JS execution and DOM manipulation are single threaded, and that thread is the UI thread, this fact cannot be changed.
> We could potentially do HTML parsing on off the main thread. Firefox
> 4 has support for this. It's unclear how much of a win this would be.
What Adam is suggesting applies not only to HTML parsing and has seemed to me to be the pragmatic and likely path for the short-term (next 1-2 years). E.g, create buffers (hidden by synchronous interfaces where possible) -- for example, queueing up calls from the parser to the selector matcher -- and then handle those in bulk. In other places, like Adam's example of a call to the parser itself, it's harder, but still possible (while being clean!) by approaches like passing around forceable futures. In a sense, such an approach is already the norm in terms of the interface between JS and the DOM/layout (at least in Firefox): calls to layout etc. are buffered up to avoid repeated or unnecessary evaluation. While I don't think this approach will expose significant parallelism, I think it would match the available hardware -- if anyone is interested in doing such a limit study, we should talk!
More information about the webkit-dev