>> 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! Shared-state parallel scripting (and concurrent DOM) seem inevitable, but these sorts of things are the minority in the performance profile. E.g., when loading a page, about half the JavaScript time is spent in non-execution tasks like parsing and code generating. They're still a concern in the sense of Amdahl's law and enabling new types of applications, but for getting the web to work satisfyingly on mobile, there seem to be bigger blockers. Until research catches up with the algorithms in browsers, exposing and exploiting coarse-level concurrency between components would be my recommendation (outside of some more obvious algorithms). Regards, - Leo _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
