Unable to reproduce this issue on reported version 62.0.3202.89 using Winodws 10 with steps mentioned below.

1. Opened attahed html file through tomcat server http://localhost:8080/webapp/ChromePerformanceIssue.html
2. Now opened devtools and recorded network activity and observed below data for different chrome versions.

57.0.2987.0          -- Load Time 8.23 sec  fin-- 1.37
58.0.3014.0          -- Load Time 10.91 sec fin -- 2.56
59.0.3050.0          -- Load Time 8.67 sec fin -- 1.39
60.0.3080.0          -- Load Time 7.30 sec fin -- 1.51 sec
60.0.3112.113      -- Load Time 6.73 sec fin- 1.27
61.0.3163.100      -- Load Time 7.40 sec fin -- 1.28
62.0.3180.0          -- Load Time 7.54 sec fin -- 1.39 sec
62.0.3202.0          -- Load Time 8.02 sec fin - 1.47 sec
62.0.3202.89        -- Load Time 8.20 sec fin -- 1.51 sec 

@Reporter: Could you please check the above observations and let us know the expected result. This would help in further triaging of the issue.

Thanks!

Hi,

I don't have these results between 62.0.3202.89 (on windows 10) and  56.0.2924.87 (on windows 2008 R2).

Can you please test with a larger file (for ex. 30 MB) as the limit of attach file is 10 MB?

Thanks

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@Reporter: Could you please attach the sample file to drive and paste the link here as we can't attach file with size >10MB. This would help in triaging issue further.

Thanks in advance!

Hi,

Here is the link: https://drive.google.com/file/d/1U9N6EJZnndKyoA-nZgPh3DftnI7zCoAQ/view?usp=sharing

Can you please confirm that you can access to the file?

Thanks

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on reported version 62.0.3202.89 and on latest canary 64.0.3264.0 using file given in comment#7.

Manual Bisect Info:
===============
Good Build:60.0.3112.0  (Finish time -- 5.65 sec) 
Bad Build:61.0.3113.0 (Finish time - 12.38 sec) 

On doing per-revison bisect seeing below error:
Traceback (most recent call last):
  File "bisect-builds.py", line 1662, in <module>
    sys.exit(main())
  File "bisect-builds.py", line 1618, in main
    evaluator, opts.verify_range)
  File "bisect-builds.py", line 1103, in Bisect
    fetch.Stop()
  File "bisect-builds.py", line 934, in Stop
    os.unlink(self.zip_file)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\sc00335628\\Downloads\\depot_tools\\475120-chrome-perf-win.zip'
Exception in thread down_fetch:
Traceback (most recent call last):
  File "C:\Users\sc00335628\Downloads\depot_tools\python276_bin\lib\threading.py", line 810, in __bootstrap_inner
    self.run()
  File "C:\Users\sc00335628\Downloads\depot_tools\python276_bin\lib\threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "bisect-builds.py", line 760, in FetchRevision
    gsutil_download(download_url, filename)
  File "bisect-builds.py", line 729, in gsutil_download
    RunGsutilCommand(command)
  File "bisect-builds.py", line 252, in RunGsutilCommand
    raise Exception('Error running the gsutil command: %s' % stderr)
Exception: Error running the gsutil command: Copying gs://chrome-test-builds/official-by-commit/Win x64 Builder/full-build-win32_475083.zip...
Resuming download for gs://chrome-test-builds/official-by-commit/Win x64 Builder/full-build-win32_475083.zip
Catching up md5 for C:\Users\sc00335628\Downloads\depot_tools\475083-chrome-perf-win.zip
Downloading ...Downloads\depot_tools\475083-chrome-perf-win.zip: 77.01 MiB/77.01 MiB
Failure: md5 signature computed for local file (yEek3PIaykcqOhpjumQBjw==) doesn't match cloud-supplied digest (QQXAmi8sv1VhSr2TiUGCWQ==). Local file (C:\Users\sc00335628\Downloads\depot_tools\475083-chrome-perf-win.zip) will be deleted..

Hence runned chromium bisect but seeing error : 

python bisect-builds.py -a win64 -g  474897 -b 475195
Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions)
Traceback (most recent call last):
  File "bisect-builds.py", line 1662, in <module>
    sys.exit(main())
  File "bisect-builds.py", line 1618, in main
    evaluator, opts.verify_range)
  File "bisect-builds.py", line 1022, in Bisect
    raise RuntimeError(msg)
RuntimeError: We don't have enough builds to bisect. revlist: []

Hence providing manual changelog.

CR:  https://chromium.googlesource.com/chromium/src/+log/60.0.3112.0..61.0.3113.0?pretty=fuller&n=10000

Unable to find suspect from above changelog. Could someone from Performance team take a look into this.

Thanks!!!

Updating narrower bisect info.

Good Build: 60.0.3112.113 -- took 5.1 sec
Bad Build: 61.0.3113.0 -- took 12.38 sec

Hi,

Do you have any updates?

Thanks.

Git log: https://chromium.googlesource.com/chromium/src/+log/60.0.3112.0..61.0.3113.0?pretty=fuller&n=10000

the .113 is a red herring as it's a bunch of cherry picks that could also be in 61.0.3113.0 or later - so it's better to compare .0 with .0.

Anyway, adding -Loading and changing status. CC'ing some folks who may be able to take a closer look.

Can we get a trace for both versions as setting up a tomcat server is not something I expect all of our devs to be able to do quickly.

How are we defining the "load finish time". When the onload event is fired?

My bisect result is:
https://chromium.googlesource.com/chromium/src/+log/488d6999c101d4a2a6b7cb3ad5b0336d7bb54069..91088a195969f5af61f404c9f02edc622cbe373a

"Add Field Trial Testing Configuration for MojoLoading" is suspicious?

It is a test configuration, and does not affect the performance in production AFAIK. tkent@, Is your bisect environment affected by the file?

Yes, according to testing/variations/README.md the configuration is enabled by default for Chromium build which bisect-build.py uses.

Confirmed.

I think I understand the reason: With the old implementation, one ResourceMsg_DataReceived contains at most 32KB, but multiple messages are sent from AsyncResourceHandler all at once. On the other hand, with the current implementation, URLResponseBodyConsumer reads at most 64KB in a task, and a post a task to read more.

Imagine 320KB body data arrives at [Mojo]AsyncResourceHandler. With the old implementation, 10 tasks for reading bytes[A] are executed and then other async tasks such as table layout[B] will run after that. With the current implementation, 5 tasks run, but for each task async tasks such as table layout follows. In other words, with the old implementations the task execution sequence looks like AAAAAAAAAABBBBBBBBBB but with the current implementation it looks like ABABABABAB.

In this case, multiple chunks are merged in the HTML parser and table relayout doesn't actually happen. Hence the old implementation is better *for this case*. I can somewhat mimic the old behavior with the current implementation, but I'm not sure if it is a performance win in general.

Interesting, in the illustrated case, does task B have higher prioritiy? or do A&B have same priority?

>#18

It looks they have the same priority based on the fact that they are executed in the FIFO order.

I had a offline chat w/ yhirano@ to have a better understanding of this bug.

I think Chrome is working as intended here. I’m marking this as WONTFIX, but please re-open if you have objections.

Currently Chrome prioritizes fast “time to meaningful paint”, after FMP is reached, then Chrome switches the scheduler mode and prioritize responsiveness to user input. We believe this provides better user experience to users.

The provided repro case unfortunately hits the pessimistic scenario in the above algorithm. Every new HTML chunk causes entire relayout of the page. The HTML contains a huge table without “table-layout: fixed” specified, so every new cell triggers a recompute of the entire column width.

In this case, I’d like to have the page author create the page in a way that new html chunk would trigger minimal re-layout of the page. This can be easily done by specifying table column width explicitly, then specifying “table-layout: fixed” on the table element.

Without the page authors help, Chrome is currently left with two suboptimal options. Page loading janks but loads faster, or page is interactive while loading but loads slower. yhirano@’s CL changed the situation from the former to the latter, which we believe is better for larger population of web pages.