Issue metadata
Sign in to add a comment
|
Displaying large strings in console is slow
Reported by
m...@mostlystatic.com,
Aug 24 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 Steps to reproduce the problem: 1. Go to a website with largish HTML, e.g. stackoveflow.com 2. Type document.body.innerHTML in the console What is the expected behavior? The string appears almost instantly. What went wrong? It takes 12 seconds for the string to appear, in both Stable and Canary. Particularly strings with lots of line breaks seem slow, if I strip the line breaks out of the HTML above the string appears within 2s. The Timeline view for DevTools shows that most of this time is spent doing a layout. Did this work before? N/A Chrome version: 52.0.2743.82 Channel: n/a OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 22.0 r0 The string has about 250k characters and 4000 lines. That's fairly large, but it should be possible to display this more quickly. Passing the string into console.log is much quicker. It's a problem I run into quite frequently and I currently have to self-police myself in case a string I'm looking happens to be unexpectedly long. After displaying a large string any further output in the console also takes a long time to appear.
,
Aug 25 2016
Sorry, I made a type in the domain name. It's stackoverflow.com. Just tried again in canary, and it's the same behavior.
,
Aug 26 2016
That's blink's fault, but probably we should handle long strings better in console to avoid this situation. Eric, could you please take a look into this?
,
Dec 6 2016
,
Mar 28 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tkonch...@chromium.org
, Aug 25 2016Labels: Needs-Feedback
Status: Untriaged (was: Unconfirmed)
25.2 MB
25.2 MB Download