I presume from your other comments that the goal of this work is responsiveness, rather than page load speed as such. I'm excited about the potential to improve responsiveness during page loading.
One question: what tests are you planning to use to validate whether this approach achieves its goals of better responsiveness? The reason I ask is that this sounds like a significant increase in complexity, so we should be very confident that there is a real and major benefit. One thing I wonder about is how common it is to have enough of the page processed that the user could interact with it in principle, yet still have large parsing chunks remaining which would prevent that interaction from being smooth. Another thing I wonder about is whether yielding to the event loop more aggressively could achieve a similar benefit at a much lower complexity cost. Having a test to drive the work would allow us to answer these types of questions. (It may also be that the test data you cited would already answer these questions but I didn't sufficiently understand it; if so, further explanation would be appreciated.) Regards, Maciej 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
