|Threaded HTML parser enabled on trunk||Adam Barth||3/1/13 3:38 PM|
== Summary ==
Eric Seidel, Tony Gentilcore, and I have been working on
multi-threading our HTML parser (see  for a design diagram).
Today, we enabled the threaded parser on trunk, which means it will be
enabled in tomorrow's Canary.
== Performance ==
The threaded HTML parser has two performance benefits: (1) reduced
improved page loading speed through pipelining.
We're measuring jankiness improvements with the maximum pause
attributable to the HTML parser when loading web pages on a Nexus 7.
Using the Telemetry performance testing framework , we see a 40%
reduction in parser-induced jankiness on the Top25 page set.
For page loading speed, we're using the normal page cyclers . On
dual-core machines across operating systems, the threaded HTML parser
is roughly a 5% improvement on intl1, a 3.5% improvement on intl2, and
an 8% improvement on moz. On single-core machines, we see a 1.5%
We don't fully understand why the threaded parser is faster on
single-core machines. My hypothesis is that tasks that want to run on
the main thread can preempt the threaded parser because the kernel
preemptively multitasks threads. With the non-threaded parser, those
tasks need to wait in the message loop because the non-threaded parser
is blocking the main thread.
== Troubleshooting ==
If you run into problems in with a Canary build that you think might
be caused the threaded HTML parser, you can try running with
--disable-threaded-html-parser. If you can reproduce the problem with
the threaded parser and not without the threaded parser, please file a
bug and CC Eric, Tony, and me. Hopefully everything will go smoothly,
but I suspect we've screwed up a few things at least. :)