Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
On Thu, Jan 10, 2013 at 9:19 PM, Maciej Stachowiak m...@apple.com wrote: 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). ---8--- OK - what test (if any) will be used to test whether the page load speed goal is achieved? All of them. :) More seriously, Chromium runs a very large battery of performance tests continuously on a matrix of different platforms, including desktop and mobile. You can see one of the overview dashboards here: http://build.chromium.org/f/chromium/perf/dashboard/overview.html The ones that are particularly relevant to this work are the various page load tests, both with simulated network delays and without network delays. For iterative benchmarking, we plan to use Chromium's Telemetry framework http://www.chromium.org/developers/telemetry. Specifically, I expect we plan to work with the top_25 dataset http://src.chromium.org/viewvc/chrome/trunk/src/tools/perf/page_sets/top_25.json?view=markup, but we might use some other data sets if there are particular areas we want to measure more carefully. 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. Consider, also, that pages might be parsing in the same process in another tab, or in a frame in the current tab. (2) It might be helpful to track max and average pause time from non-parsing sources, for the sake of comparison. If you looked at the information Eric provided in his initial email, you might have noticed https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0, which is precisely that. 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. I'm quite aware of the complexity of multithreaded code having written a great deal of it for Chromium. One of the things I hope comes out of this project is a good example of how to do multithreaded processing in WebCore. Currently, every subsystem seems rolls their own threading abstractions, I think largely because there hasn't been a
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote: On Thu, Jan 10, 2013 at 9:19 PM, Maciej Stachowiak m...@apple.com wrote: 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). ---8--- OK - what test (if any) will be used to test whether the page load speed goal is achieved? All of them. :) More seriously, Chromium runs a very large battery of performance tests continuously on a matrix of different platforms, including desktop and mobile. You can see one of the overview dashboards here: http://build.chromium.org/f/chromium/perf/dashboard/overview.html The ones that are particularly relevant to this work are the various page load tests, both with simulated network delays and without network delays. For iterative benchmarking, we plan to use Chromium's Telemetry framework http://www.chromium.org/developers/telemetry. Specifically, I expect we plan to work with the top_25 dataset http://src.chromium.org/viewvc/chrome/trunk/src/tools/perf/page_sets/top_25.json?view=markup, but we might use some other data sets if there are particular areas we want to measure more carefully. 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. Consider, also, that pages might be parsing in the same process in another tab, or in a frame in the current tab. (2) It might be helpful to track max and average pause time from non-parsing sources, for the sake of comparison. If you looked at the information Eric provided in his initial email, you might have noticed https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0, which is precisely that. 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. I'm quite aware of the complexity of multithreaded code having written a great deal of it for Chromium. One of the things I hope comes out of this project is a good example of how to do multithreaded processing in WebCore.
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
Your comments here make me feel more positively towards this project. In particular, I'm happy that: - There actually will be meaningful testing. - You're prepared to abandon this approach if it doesn't meet its perf goals (presumably at minimum no regression to page load time or responsiveness while loading, and meaningful improvement to at least one of these). - The shared-nothing message-passing approach to threading sounds likely to be a relatively less complex/fragile approach to threading than most others. Thanks for following up. I have a comment on a tangential point that I'll split into another thread. Cheers, Maciej On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote: On Thu, Jan 10, 2013 at 9:19 PM, Maciej Stachowiak m...@apple.com wrote: 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). ---8--- OK - what test (if any) will be used to test whether the page load speed goal is achieved? All of them. :) More seriously, Chromium runs a very large battery of performance tests continuously on a matrix of different platforms, including desktop and mobile. You can see one of the overview dashboards here: http://build.chromium.org/f/chromium/perf/dashboard/overview.html The ones that are particularly relevant to this work are the various page load tests, both with simulated network delays and without network delays. For iterative benchmarking, we plan to use Chromium's Telemetry framework http://www.chromium.org/developers/telemetry. Specifically, I expect we plan to work with the top_25 dataset http://src.chromium.org/viewvc/chrome/trunk/src/tools/perf/page_sets/top_25.json?view=markup, but we might use some other data sets if there are particular areas we want to measure more carefully. 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. Consider, also, that pages might be parsing in the same process in another tab, or in a frame in the current tab. (2) It might be helpful to track max and average pause time from non-parsing sources, for the sake of comparison. If you looked at the information Eric provided in his initial email, you might have noticed https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0, which is precisely that. 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
[webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote: 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. Is that really the case? If so, I'm surprised that the patches for the shared memory cache and the NetworkProcess landed. I raised similar questions to the ones you're raising now, but the folks purposing those changes basically ignored me and landed their patches anyway. NetworkProcess itself exists primarily for correctness reasons in the face of process-per-tab. I hope the idea of handling networking outside any of the web/render processes in a process-per-tab architecture is not itself controversial. What I know is controversial, and I believe merits further follow-up discussion, is the choice of where proxying of networking to an outside process should hook in - whether at the ResourceHandle layer (as Chromium does it), or at the CachedResource layer, as WebKit2 is doing it. That choice involves hypotheses about both performance and appropriate architecture. I feel that the WebKit2 folks have not provided sufficient public data to fully justify the choice of where to hook things in, and I will encourage things to do so. On the other hand, Chromium folks historically did not really provide a lot of data or justification for why the ResourceHandle was the right place. Rather, it was presented as a constraint and a must-have for merging back to the WebKit repository. Long term, it is obviously somewhat regrettable if we end up diverging on this point, and therefore having two different insertion points for proxying, as that makes WebKit overall more complex. I think your whitepaper on the topic was a good start on outlining some of the pros and cons. I commented on it a bit in email and via the comment system, but discussion died down (probably due to vacations and then the holidays). Here it is for reference of others: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit?pli=1 In addition to my previous comments, I believe some topic not yet fully covered by your whitepaper are: - Hooking in proxying at the ResourceHandle layer may require threading information through ResourceHandle that it logically should not need to know (if one thinks of it as a an abstraction on top of a low-level networking API), such as association with a specific frame/page, or - How to connect loading mechanisms that bypass ResourceHandle or otherwise bypass the network stack (e.g. Application Cache, WebArchives, blob: URLs (currently implemented as a magic ResourceHandle subclass), etc. The two approaches have different architectural implications for this type of feature. I am not sure offhand which approach is cleaner or whether one way or the other has more pragmatic benefits. I'll add also that it seems possible in principle to make all WebCore loading go through the CachedResource layer, jut as it's possible to have it all go through the ResourceHandle layer, and it's likely beneficial to do so though the benefits in cases of more marginal load types may be small. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unprefixed and prefixed DOM events.
Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the unprefixed one *only* forcing people to rely on the unprefixed. It seems that this approach is an elegant one and allows us to remove later in the future the support for prefixed transitions (including the events). As a side note Opera is acting the same as the proposed solution. Now obviously prefixed and unprefixed events in the DOM is something new because it never happens in the past so we don't have support for having such a mechanism for event delivery. I thought that we could somewhere in the Animation/Transition code be smart and try to figure which event to send but it practically impossible to access the EventListenerMap so I thought we could support it somehow generically in the DOM events code. It will be useful for the animations and maybe in the future (we're not really sure if prefixed event will again show but who knows). So I did a first patch there [2] and I would like to gather feedback whether the approach is correct (I don't know much the DOM related code) or if somebody has a better idea on how to resolve the problem. Also if I have missed something, please point it to me. The patch doesn't include the support for HTML ontransitionend attribute which I prefer to do in a later patch. Thanks. [1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property [2] https://bugs.webkit.org/show_bug.cgi?id=105647 -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixed and prefixed DOM events.
That does sound like a tricky problem. Your approach sounds reasonable to me. If you like, we can use the FeatureObserver [1] to estimate how often these various cases occur. Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote: Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the unprefixed one *only* forcing people to rely on the unprefixed. It seems that this approach is an elegant one and allows us to remove later in the future the support for prefixed transitions (including the events). As a side note Opera is acting the same as the proposed solution. Now obviously prefixed and unprefixed events in the DOM is something new because it never happens in the past so we don't have support for having such a mechanism for event delivery. I thought that we could somewhere in the Animation/Transition code be smart and try to figure which event to send but it practically impossible to access the EventListenerMap so I thought we could support it somehow generically in the DOM events code. It will be useful for the animations and maybe in the future (we're not really sure if prefixed event will again show but who knows). So I did a first patch there [2] and I would like to gather feedback whether the approach is correct (I don't know much the DOM related code) or if somebody has a better idea on how to resolve the problem. Also if I have missed something, please point it to me. The patch doesn't include the support for HTML ontransitionend attribute which I prefer to do in a later patch. Thanks. [1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property [2] https://bugs.webkit.org/show_bug.cgi?id=105647 -- Software Engineer @ Intel Open Source Technology Center ___ 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
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote: 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. Is that really the case? If so, I'm surprised that the patches for the shared memory cache and the NetworkProcess landed. I raised similar questions to the ones you're raising now, but the folks purposing those changes basically ignored me and landed their patches anyway. NetworkProcess itself exists primarily for correctness reasons in the face of process-per-tab. I hope the idea of handling networking outside any of the web/render processes in a process-per-tab architecture is not itself controversial. I don't want delve too deeply into this issue because it's primarily a WebKit2 concern. However, I'll note that in Chromium, networking is just a thread in the UIProcess rather than a separate process. I haven't really thought though the consequences of that design choice. My point is more that folks just started landing patches for the NetworkProcess without discussing the design with the community. That's fine if you're not interested feedback from the community, but I've also heard repeated requests to share more code between Chromium and WebKit2. If you don't seek feedback on your designs, it's unlikely that you'll happen to design something that Chromium will be able to adopt in the future. Put another way, I don't think it's reasonable to simultaneously design WebKit2 without community feedback and also to complain when Chromium doesn't adopt WebKit2 (in part or in whole). What I know is controversial, and I believe merits further follow-up discussion, is the choice of where proxying of networking to an outside process should hook in - whether at the ResourceHandle layer (as Chromium does it), or at the CachedResource layer, as WebKit2 is doing it. That choice involves hypotheses about both performance and appropriate architecture. I feel that the WebKit2 folks have not provided sufficient public data to fully justify the choice of where to hook things in, and I will encourage things to do so. On the other hand, Chromium folks historically did not really provide a lot of data or justification for why the ResourceHandle was the right place. Rather, it was presented as a constraint and a must-have for merging back to the WebKit repository. To me, that's seems like a pretty revisionist version of history. At the time Chromium landed, it wasn't at all practical to hook in at the cached resource layer because many (most?) loading codepaths bypassed the memory cache. It's only because of Nat's work to unify the loader code paths that it's even possible today. As Brady found, it wasn't even possible when he started out because main resources didn't flow through the memory cache until this past month. Long term, it is obviously somewhat regrettable if we end up diverging on this point, and therefore having two different insertion points for proxying, as that makes WebKit overall more complex. Agreed. I think your whitepaper on the topic was a good start on outlining some of the pros and cons. I commented on it a bit in email and via the comment system, but discussion died down (probably due to vacations and then the holidays). Here it is for reference of others: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit?pli=1 In addition to my previous comments, I believe some topic not yet fully covered by your whitepaper are: - Hooking in proxying at the ResourceHandle layer may require threading information through ResourceHandle that it logically should not need to know (if one thinks of it as a an abstraction on top of a low-level networking API), such as association with a specific frame/page, or - How to connect loading mechanisms that bypass ResourceHandle or otherwise bypass the network stack (e.g. Application Cache, WebArchives, blob: URLs (currently implemented as a magic ResourceHandle subclass), etc. The two approaches have different architectural implications for this type of feature. I am not sure offhand which approach is cleaner or whether one way or the other has more pragmatic benefits. I'll add also that it seems possible in principle to make all WebCore loading go through the CachedResource layer, jut as it's possible
