[webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

Zoltan Herczeg zherczeg at webkit.org
Thu Jan 10 00:11:02 PST 2013

Parsing, especially JS parsing still takes a large amount of time on page
loading. We tried to improve the preload scanner by moving it into
anouther thread, but there was no gain (except some special cases).
Synchronization between threads is surprisingly (ridiculously) costly,
usually worth for those tasks, which needs quite a few million
instructions to be executed (and tokenization takes far less in most
cases). For smaller tasks, SIMD instruction sets can help, which is
basically a parallel execution on a single thread. Anyway it is worth
trying, but it is really challenging to make it work in practice. Good


> On Jan 9, 2013, at 10:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Wed, 9 Jan 2013, Eric Seidel wrote:
>>> The core goal is to reduce latency -- to free up the main thread for
>>> JavaScript and UI interaction -- which as you correctly note, cannot be
>>> moved off of the main thread due to the "single thread of execution"
>>> model of the web.
>> Parsing and (maybe to a lesser extent) compiling JS can be moved off the
>> main thread, though, right? That's probably worth examining too, if it
>> hasn't already been done.
> 100% agree.
> However, the same problem I brought up about tokenization applies here: a
> lot of JS functions are super cheap to parse and compile already, and the
> latency of doing so on the main thread is likely to be lower than the
> latency of chatting with another core.  I suspect this could be alleviated
> by (1) aggressively pipelining the work, where during page load or during
> heavy JS use the compilation thread always has a non-empty queue of work
> to do; this will mean that the latency of communication is paid only when
> the first compilation occurs, and (2) allowing the main thread to steal
> work from the compilation queue.  I'm not sure how to make (2) work well.
> For parsing it's actually harder since we rely heavily on the lazy parsing
> optimization: code is only parsed once we need it *right now* to run a
> function.  For compilation, it's somewhat easier: the most expensive
> compilation step is the third-tier optimizing JIT; we can delay this as
> long as we want, though the longer we dela
>  y it, the longer we spend running slower code.
> Hence, to make parsing concurrent, the main problem is figuring out how to
> do predictive parsing: have a concurrent thread start parsing something
> just before we need it.  Without predictive parsing, making it concurrent
> would be a guaranteed loss since the main thread would just be stuck
> waiting for the thread to finish.
> To make optimized compiles concurrent without a regression, the main
> problem is ensuring that in those cases where we believe that the time
> taken to compile the function will be smaller than the time taken to awake
> the concurrent thread, we will instead just compile it on the main thread
> right away.  Though, if we could predict that a function was going to get
> hot in the future, we could speculatively tell a concurrent thread to
> compile it fully knowing that it won't wake up and do so until exactly
> when we would have otherwise invoked the compiler on the main thread (that
> is, it'll wake up and start compiling it once the main thread has executed
> the function enough times to get good profiling data).
> Anyway, you're absolutely right that this is an area that should be
> explored.
> -F
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list