On Jan 10, 2013, at 12:07 PM, Adam Barth <aba...@webkit.org> wrote: > > On Thu, Jan 10, 2013 at 12:37 AM, Maciej Stachowiak <m...@apple.com> wrote: >> 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. > > The goals are described in the first link Eric gave in his email: > <https://bugs.webkit.org/show_bug.cgi?id=106127#c0>. Specifically: > > ---8<--- > 1) Moving parsing off the main thread could make web pages more > responsive because the main thread is available for handling input > events and executing JavaScript. > 2) Moving parsing off the main thread could make web pages load more > quickly because WebCore can do other work in parallel with parsing > HTML (such as parsing CSS or attaching elements to the render tree).
OK - what test (if any) will be used to test whether the page load speed goal is achieved? > --->8--- > >> One question: what tests are you planning to use to validate whether this >> approach achieves its goals of better responsiveness? > > The tests we've run so far are also described in the first link Eric > gave in his email: <https://bugs.webkit.org/show_bug.cgi?id=106127>. > They suggest that there's a good deal of room for improvement in this > area. After we have a working implementation, we'll likely re-run > those experiments and run other experiments to do an A/B comparison of > the two approaches. As Filip points out, we'll likely end up with a > hybrid of the two designs that's optimized for handling various work > loads. I agree the test suggests there is room for improvement. From the description of how the test is run, I can think of two potential ways to improve how well it correlates with actual user-perceived responsiveness: (1) It seems to look at the max parsing pause time without considering whether there's any content being shown that it's possible to interact with. If the longest pauses happen before meaningful content is visible, then reducing those pauses is unlikely to actually materially improve responsiveness, at least in models where web content processing happens in a separate process or thread from the UI. One possibility is to track the max parsing pause time starting from the first visually non-empty layout. That would better approximate how much actual user interaction is blocked. (2) It might be helpful to track max and average pause time from non-parsing sources, for the sake of comparison. These might result in a more accurate assessment of the benfits. > >> 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. > > If you're interested in reducing the complexity of the parser, I'd > recommend removing the NEW_XML code. As previously discussed, that > code creates significant complexity for zero benefit. Tu quoque fallacy. From your glib reply, I get the impression that you are not giving the complexity cost of multithreading due consideration. I hope that is not actually the case and I merely caught you at a bad moment or something. (And also we agreed to a drop dead date to remove the code which has either passed or is very close.) > >> 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. > > Yielding to the event loop more could reduce the "ParseHTML_max" time, > but it cannot reduce the "ParseHTML" time. Generally speaking, > yielding to the event loop is a trade-off between throughput (i.e., > page load time) and responsiveness. Moving work to a background > thread should let us achieve a better trade-off between these > quantities than we're likely to be able to achieve by tuning the yield > parameter alone. I agree that is possible. But it also seems like making the improvements that don't impose the complexity and hazards of multithreading in this area are worth trying first. Things such as retuning yielding and replacing the preload scanner with (non-threaded) speculative pre-tokenizing as suggested by Antti. That would let us better assess the benefits of the threading itself. > >> 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.) > > If you're interested in building such a test, I would be interested in > hearing the results. We don't plan to build such a test at this time. If you're actually planning to make a significant complexity-imposing architectural change for performance reasons, without any way to test whether it delivers the claimed performance benefits, or how it compares to less complex approaches, then why should any rational person agree with that approach? When attempting to improve performance, the burden of proof is on the person proposing the performance improvement, not on others to create a test to figure out if the performance improvement works. It's not valid to respond to a request for performance testing info with the equivalent of "patches welcome". But you and others have actually cited a performance test and described how to run of it, and perhaps even shown openness to improving it. So here again, I hope your words merely sound more negative than what you actually mean. I don't understand why you would say you don't plan to build a test when above you cited a test and your plans to run it before and after. Am I missing some nuance? Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
