Punting this up for Loader triage - the NetLog (Event 1998) shows a series of 32K reads consistent with IPC'ing 32K chunks over to the renderer. There's periodic stalls, and the stalls seem suggestive of the renderer taking time before issuing another read request.

Would you also be willing to record an Event Trace (see https://www.chromium.org/developers/how-tos/submitting-a-performance-bug or https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs for details) which will help debug this further.

@rsleevi Thanks for looking into it, I attached a trace.

Since the page takes about 23s to load I let the trace capture all of that instead of the recommended 10s from the article, let me know if I should capture a shorter one.

Btw. this is not isolated to my machine, everyone using a Mac+Chrome is hitting this here.

Deleted: trace_tracing.json.gz 2.6 MB

trace_tracing.json.gz 2.6 MB Download

Warning to future triagers: I have no idea what I'm doing re: chrome://tracing, but it appears that the stalls (which can last several hundred MS to multiple seconds) appear to be being caused by FrameView::performLayout as part of style/layout calculation. I'm not sure exactly what component this best belongs to, but I'm randomly slapping a Layout label on it and hoping emil would have insight into why Safari does so much better than us for this page.

It looks like these layouts are triggered by the background parser continually sending tokens to the main thread. The page is so big that each additional layout is really expensive.

sendTokensToMainThread should only be getting invoked on
 - end of input
 - script begin
 - script end

My guess is that the bg tokenizer is streaming data as fast as possible and keeps hitting end of input. Adding kouhei@ for further triage, as this could be a parser issue.

FWIW I've tested with Edge and Firefox on Windows too and it's pretty much instantaneous there while Chrome shows the same slow loading as on Mac.

This might be due to a combination of long tokens without spaces (which disables a text shaping cache) and Mac Specific AAT fonts (for which text layout is much slower than other fonts).

Loading the file from disk it takes ~27 seconds for the page to render for me. About 7 seconds of that is layout. Changing the font reduces it to about 5 as does removing the pre-wrap style.

Interesting :) Saving https://jenkins.mono-project.com/job/test-mono-mainline-linux/label=debian-8-armel/204/consoleText to disk (== plain text file without html) and loading it up in Chrome shows the same slow behavior.

The layout time is mostly spent in shaping (as the cache cannot be used for a majority of the strings). This is especially bad on Mac where AAT shaping is quite slow.

This still does not explain the non-layout time though.

alexander.koeplinger, could you record a trace with more options enabled (for example, check all categories listed in the left side, as in the screenshot)? 

Sorry, I thought with enough options we could see the time-taking task in the trace, but it's not true according to nhiroki@'s tracing. Removed Needs-Feedback label.

Regarding #c8:

> Changing the font reduces it to about 5 as does removing the pre-wrap style.

How did you change the font? Would be awesome if I could use this as a workaround in the meantime :)

This is frustratingly slow for me too for similar sized files. I have to download large docs and open them in sublime/whatever nowadays.

Repro unavailable, unable to reproduce.

 Issue 776261  has been merged into this issue.