[Webkit-unassigned] [Bug 106127] [meta] HTML parser shouldn't block the main thread

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 8 15:30:00 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=106127





--- Comment #10 from Antti Koivisto <koivisto at iki.fi>  2013-01-08 15:31:54 PST ---
(In reply to comment #7)
> > Over a run of bunch of real world web sites we seem to have ~3% of main thread CPU time in the HTML tokenization and parsing (excluding the actual tree building, the most expensive part).
> 
> Why you say "tree building," do you mean the work down by the HTMLTreeBuilder object or the actually parserAppendChild/attach calls?  We should be able to move HTMLTreeBuilder onto the background thread, but we probably would not be able to move parserAppendChild or attach.

I was pruning out entire HTMLTreeBuilder::constructTreeFromAtomicToken(). Pruning more carefully (calls to Element functions only) leaves ~3.5% in total.

> nduca did some measurements with Chromium's telemetry profiler (which uses the inspector timeline's notion of what constitutes HTML parsing time).  On a selection of 25 popular web sites, he sees the parser using between 2% and 8% of main thread CPU time (with an average of 5%).  Some examples on the high end (i.e., >=7%) are games.yahoo.com, www.youtube.com, http://en.wikipedia.org/wiki/Wikipedia, and pinterest.com.

I would like to see measurements done without relying on inspector infrastructure (for example by simple instrumentation code) so we know what exactly is being measured. 

As I said I think this is worth doing based on the current data already. However it would be good to realistic understanding what kinds of gains to expect.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list