I think your biggest challenge will be ensuring that the latency of shoving things to another core and then shoving them back will be smaller than the latency of processing those same things on the main thread.
For small documents, I expect concurrent tokenization to be a pure regression because the latency of waking up another thread to do just a small bit of work, plus the added cost of whatever synchronization operations will be needed to ensure safety, will involve more total work than just tokenizing locally. We certainly see this in the JSC parallel GC, and in line with traditional parallel GC design, we ensure that parallel threads only kick in when the main thread is unable to keep up with the work that it has created for itself. Do you have a vision for how to implement a similar self-throttling, where tokenizing continues on the main thread so long as it is cheap to do so? -Filip On Jan 9, 2013, at 6:00 PM, Eric Seidel <e...@webkit.org> wrote: > We're planning to move parts of the HTML Parser off of the main thread: > https://bugs.webkit.org/show_bug.cgi?id=106127 > > This is driven by our testing showing that HTML parsing on mobile is > be slow, and long (causing user-visible delays averaging 10 frames / > 150ms). > https://bug-106127-attachments.webkit.org/attachment.cgi?id=182002 > Complete data can be found at [1]. > > Mozilla moved their parser onto a separate thread during their HTML5 > parser re-write: > https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading > > We plan to take a slightly simpler approach, moving only Tokenizing > off of the main thread: > https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit > The left is our current design, the middle is a tokenizer-only design, > and the right is more like mozilla's threaded-parser design. > > Profiling shows Tokenizing accounts for about 10x the number of > samples as TreeBuilding. Including Antti's recent testing (.5% vs. > 3%): > https://bugs.webkit.org/show_bug.cgi?id=106127#c10 > If after we do this we measure and find ourselves still spending a lot > of main-thread time parsing, we'll move the TreeBuilder too. :) (This > work is a nicely separable sub-set of larger work needed to move the > TreeBuilder.) > > We welcome your thoughts and comments. > > > 1. > https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0 > (Epic thanks to Nat Duca for helping us collect that data.) > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
