1. How can this be reproduced and narrowed down to find the cause without at least the simplest html page with code that uses test.json items?

2. What do you see in v56 canary? 

3. What do you see in devtools Timeline profiler?

1. Just open the test.json file in the browser
2 and 3: see attached screenshots

Deleted: chrome56.png 35.5 KB

	chrome56.png 35.5 KB View Download

Deleted: chrome56timeline.png 57.4 KB

	chrome56timeline.png 57.4 KB View Download

Deleted: chrome48timeline.png 93.1 KB

	chrome48timeline.png 93.1 KB View Download

Bisect: 361463 (good) - 361463 (bad), 49.0.2574.0
Changelog: https://chromium.googlesource.com/chromium/src/+log/20f3b2d0..fa7fc32c?pretty=fuller
Suspecting https://crrev.com/1474673003 tracked in  issue 404597 

======================
Exact STR:
1. open devtools network tab
2. navigate to test.json from the bug report (load it from disk or a local webserver)
3. observe the DOMContentLoaded time in statusbar

Chrome 48: around 200ms
Chrome 49: around 850ms

The page is rendered 4+ times slower!

Definitely caused by https://crrev.com/1474673003 tracked in  issue 404597 .

Proof: disabling the complex text feature introduced in the abovementioned patch makes the page load as fast as in Chrome 48. The feature may be disabled by running an affected build (after 49.0.2574.0) with a command line switch --disable-blink-features=AlwaysUseComplexText

It should be noted that the feature cannot be disabled since canary 56.0.2903.0 because issue 402536 removed the corresponding feature entry.

Koji, is this a duplicate of an existing issue regarding some of the non human-readable code display issues we had?

FWIW, a slightly less huge speed drop (200ms vs 550ms) occurs even on a properly formatted "human-readable" text inside PRE element in html file, see the attached archive. The difference can be easily measure on any build in 49.0.2574.1 - 56.0.2902.0 range by using the abovementioned command line switch.

The attachment for #9

Deleted: test.zip 36.4 KB

test.zip 36.4 KB Download

Thanks for the additional test case. Yes, the test in #9 and the original content are similar in the sense that JSON code or structured data such as large XML files often have variable names, identifiers, or whitespace-compressed, non-spac-breakable sections of data that frequently exceed the word cache character limit. Choice of the word "non human readable" might have been misleading: What I meant to describe is that this sort of code/data has different patterns from natural language - where the word cache is more effective.

#11, really human-readable natural language English text from wikipedia in two PRE elements (see the attached archive) is rendered 2 times slower (210ms vs 427ms).

Deleted: test-human-readable-from-wikipedia.zip 171 KB

test-human-readable-from-wikipedia.zip 171 KB Download

More results on the natural language file in #12 as measured by repeatedly refreshing the page with devtools opened on network panel using the good and bad builds.

3x speed drop (110ms vs 325ms) on average

Thank you for the report from me too. We acknowledge that we're sometimes not as fast as Chrome 48. We're in the process of improving layout in multiple phases:
1. We had fast layout but oftentimes produced incorrect results.
2. We fixed lots of incorrectness.
2.5. We fixed n^2/n! issues that were stood out by phase 2.
3. We will make it fast again.

Currently we're working on 3, and until it's complete, our goals are as below:
1. We're not slower than other browsers for human readable pages.
2. We're not unreasonably slow on non-human pages.

By using the test page attached in #12 on my machine:
Chrome 56.0.2909.0: 626ms (537ms in layout)
Edge: 1500ms (775ms in layout)
Firefox: 1200ms (742ms in layout)

So while this is not really an ideal situation, I think we're still faster than other browsers, and please look forward to Chrome being even faster again.