Page-loading performance regression occurred on Windows Chrome M50
Reported by
lingyun....@intel.com,
Jul 5 2016
|
||||||||||||||
Issue descriptionWhen running a page-loading benchmark BrowsingBench on Windows IA platform, the performance has a ~8% regression from M49.0.2623.75 to M50.0.2661.94. We took one of the pages 'Baidu.com' for analysis, and identified that the main gap of page-loading time can be reflected on the traces of Netlog of loading page file. As shown by the attached screenshot files, an extra period 'DELEGATE_INFO' with ~70ms duration was observed on M50 when compared with the result of M49. The 70ms duration is almost the page-loading time gap between M49 (~180ms) and M50 (~250ms), which caused the regression on page-loading performance. I also attach a simple case to reproduce the above problem: (1) Run 'test.html' in the attached file 'test.zip', which is a very simple html file and would load for 20 times (2) Record the trace and zoom in to select Netlog trace of loading html file for one of the page-loading period If we compare the traces, we could also observe extra 'DELEGATE_INFO' period on M50 than M49.
,
Jul 11 2016
We further make a breakdown and identify the patch that caused the regression as 'master@{#373557}' (Review URL: https://codereview.chromium.org/1659163006)
The patch changes the behavior of NavigationResourceThrottle, and the resource on the IO thread would be deferred until the UI thread checks are performed by the UI thread NavigationThrottles.
This makes a longer resource loading time for the same page, and thus introducing regression on page-loading performance.
Details in traces are also attached.
,
Jul 14 2016
Assigning to mkwst@ as per C#2 for further investigation of this. lingyun.cai@: Could you also check the same on the latest stable(51.0.2704.106).
,
Jul 15 2016
Check on 51.0.2704.106, where the regression still exists. Details are attached, and the same results with M50 could be observed.
,
Jul 15 2016
Hrm. I don't think we can avoid the thread hop if we want this kind of check, and I think we need this kind of check for a number of features. clamy@, nasko@: Any ideas about how we could improve the performance of this piece of navigation? lingyun.cai@: I'm not familiar with BrowsingBench, can you point me to some details? Moreover, are you only seeing this performance regression on one architecture?
,
Jul 15 2016
mkwst@: Thanks for your comments. Browsing Bench is a benchmark for page-loading performance, which measures complete user-experience from the click/touch on a URL to final page rendered and scrolled on the screen. More details can be referred at the official website: http://www.eembc.org/browsingbench/about.php Actually, we build a simple test case that loads one html for 20 times to reproduce the regression. From the trace details attached, the most common scenario we observe is that the duration of the thread hop still brings regression when loading the html file (i.e., 16.759ms -> 19.570ms). We also check on the Android Chrome. For Browsing Bench case 'Baidu', the result is basically no regression observed, because the most common scenario is that UI thread is idle when the checks are performing, thus the IO thread is not deferred by other tasks on UI thread, as shown by the attachment 'Android-M50-Baidu'. But for the test case, IO thread may still be deferred for UI thread and consequently introduces an extra time duration, see attachment 'Android-M50-TestCase'. If any data or tests needed, please let me know :)
,
Jul 18 2016
The regression popped up on the performance bots as well. Basically, in order for us to move with the navigation changes, we had to introduce the NavigationThrottle interface. This added extra thread hops on desktop, but not on Android (hence the no-regression). It did not add thread hops on Android since we converted the InterceptionResourceThrottle into a NavigationThrottle, and the InterceptionResourceThrottle was making that extra-thread hop anyway. We knew there would be a small regression, but it was necessary to proceed with PlzNavigate, which will bring bigger performance improvements in the future. Note that with PlzNavigate enabled, there will only be one extra thread hop on redirect (but we won't be doing process hop, so all in all it's a win). Tldr: yes this was expected when we landed NavigationThrottles and it can't be avoided. It should go away when we launch PlzNavigate.
,
Jul 19 2016
clamy@: Much appreciated for your comments. Still we have some concerns that may need your help. We really want to know if the regression popped on your performance bots is aligned with ours, it would be better if you could inform us how much the regression is. For now, desktop and Android act differently on NavigationThrottle, but when PlzNavigate is enabled, will the desktop and Android still have different code path? Besides, do you have a schedule for landing the PlzNavigate? We are very interested in this new feature and really want to know more and help, if possible :)
,
Nov 18 2016
,
Nov 10 2017
,
Feb 18 2018
|
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by hong.zh...@intel.com
, Jul 7 2016