BTW, downgraded to Chrome 38 and the debugger was MUCH MUCH faster.  Was able to work for a minute before Chrome re-updated. Is there a way to temporarily downgrade so I can continue work?  I have gone through most of the obvious steps to disable auto-update but it doesn't take.  Can you post the canonical steps to downgrade?

UPDATE:  I downgraded to Chrome 49 and disabled auto-updates.  The inspector/debugger is performant and it works like a charm.  There is definitely something wrong with Chrome 53's dev tools performance.  I can't attest to 50, 51, or 52 at the moment but will test this weekend.  I believe sluggishness started with 53.

I see same issue on OS X 10.11.1 (15B42), running Version 51.0.2704.106 (64-bit)

Weirdly enough, the workaround suggested at http://stackoverflow.com/questions/36913727/google-chrome-developer-tools-works-very-slow helps: it seems the problem only happens when the devtools pane is docked at the bottom of the window, or detached as a separate window. When it is docked at the right side of the window, the devtools are quite responsive.

Do you guys have a project that's online that we can test this with? 
Can you reproduce it with an empty Chrome profile?

If you can profile devtools itself, it'd help give us an indication of what work is happening.

 Issue 624799  has been merged into this issue.

Our project is currently not available online and in deep development.  To reiterate, we have downgraded to 49.  It works well.  As for empty profile, how is that done on an iMac?  Is it more than deleting ~/Library/Google'?  Thanks.

UPDATE:
My machine crashed and, as a result, Chrome updated from the snappy 49 inspector to the 51.  51's inspector starts ok (although still not as snappy as 49) but it becomes progressively sluggish again and unworkable after a couple of hours.

IMPORTANT:  In 51 icognito, the inspector seems performant although I haven't worked in incog for long periods to see if it remains snappy or it will eventually become sluggish.

IMPORTANT: When I log out of 51, it seems snappier but not as snappy as 49.

Could you guys please check if you experience this behavior on Chrome Canary?
Also, whenever the devtools become sluggish, could you open devtools on devtools and record a timeline of the "sluggish" behavior? This would help us a lot!

Hi,  I can only run 'inspector on inspector' when undocked. The sluggishness seems to occur only when inspector is docked 'below' ('side' or 'undocked' is better).  In the 'inspector in inpsctor' I attempted to re-dock but the 3 dots no longer have a dock option.  (SO here: http://stackoverflow.com/questions/12291138/how-do-you-inspect-the-web-inspector-in-chrome) 

As for Canary,I just now downloaded it.  I will update after I've run the inspector for awhile.  In 51, the inspector gradually becomes sluggish so I need to see what Canary does as time passes.  Also note in my previous comments, when 51's inspector is in fact performant.

I've also had problems with DevTools since 49. In fact, in 51/52 it is sluggish for me from the start, not gradually. Sluggish enough to basically be unusable. That may be that I'm loading a very large JS codebase (250K+ LOC). I just tried Canary (Version 53.0.2785.0 canary (64-bit)
) using the exact same testing scenario and it seems quite a bit faster, but not as fast as 49 and earlier.

I'm on MacOS, if that makes any difference.

#12: are you sure you picked the correct inspector to re-dock? This works for me:
1. undock inspector
2. open inspector-on-inspector
3. focus first inspector and re-dock it to bottom

#13: do you experience this in dock-to-bottom only as well?

And once you have the inspector-on-inspector in place, here's' how to capture a timeline for us:  https://www.chromium.org/devtools/capturing-a-timeline-trace

I experience this slowdown no matter where the inspector is docked.

I had found another major perf issue before (for V8 in general), but the comments on that bug say that it was patched in 51, so now I'm not sure this is the same problem.

https://bugs.chromium.org/p/chromium/issues/detail?id=606207

Here's the timeline data I captured from Version 52.0.2743.60 beta (64-bit), as per the instructions in comment #15. The operations I was trying to perform include typing statements to eval in the console (wherein I watched individual characters render one...at...a...time) and opening (big, 10KLOC) files and watching them render slowly in the Source view.

Deleted: TimelineRawData-20160701T154301.json.gz 1.5 MB

TimelineRawData-20160701T154301.json.gz 1.5 MB Download

Thanks, that was very helpful! This looks like a regression somewhere inside the rendering engine.

Could you please record the trace for us? This will give us more data to dig into. 

How to record a trace: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

UPDATE 1: Thanks for clarifying on how to timeline the 51 inspector itself.  The inspector-in-inspector was exactly covering the original 're-dockable' inspector. I have attached the zipped timeline data.  Note, most time is spent rendering which probably explains the sluggishness.  This particular timeline corresponds to running between 3-4 breakpoints.

UPDATE 2: As requested, I installed Canary and ran the inspector for about an hour.  It's performant and is not sluggish like 51.

Deleted: MODEEMOK_TimelineRawData-20160701T180410.zip 7.4 MB

MODEEMOK_TimelineRawData-20160701T180410.zip 7.4 MB Download

Here's the tracing information per your instructions in #18.

Note that, this time around, I was *not* able to repro the slow keystroke behavior, but I could repro the slow JavaScript file opening and rendering in the Source view (actually both opening and/or trying to switch between files by clicking on their tabs).

Deleted: trace_Fri_Jul_01_2016_4.20.55_PM.json.gz 7.0 MB

trace_Fri_Jul_01_2016_4.20.55_PM.json.gz 7.0 MB Download

UPDATE:  Here is my trace file.   51's inspector, here, is very slow:

Deleted: trace_MO_DEEMOK_TRACE.json.gz 20.0 MB

trace_MO_DEEMOK_TRACE.json.gz 20.0 MB Download

#19, #21: thanks for the timeline!

To everybody: are your javascript files minified and contain long lines? Does the behavior reproduces if you don't open large minified javascript files?

My JS files are not minified and don't contain long lines. They are big, though. 2 or 3 files open simultaneously that each contain 15K-20K LOC. Note that prior versions of DevTools handled these no problem.

Yes, there are plenty of large minified javascript files on my projects. (typically, http://d3js.org/d3.v3.min.js and http://d3js.org/d3.v4.min.js, a few others like that)

Hi Koji, Emil,

Could this be related to the  crbug.com/593679  or some other font rendering issue on Mac?

#22, except for 3d party libs (AJS, etc), our files are not minified at development stage.

Is this really mac-only?

If this is:
- Occurs on all platforms.
- Occurs either in Network/Headers view, or device view when URL is long (not sure about the latter)
- Get worse when width is narrow (might explain only when docked-on-right, but the same performance should be observed by undock and make the window narrower)
then this must be  issue 622810 .

But I'm not sure if this is it or a separate issue from comments, nor I could find repro steps.

Now, when  issue 622810  is fixed, do you guys still experience this behavior on Canary?

Canary's always worked for me.  I see sluggishness on 51.X.  No problem with 49.X.

Canary (54) is working fine for me. In fact, 53 worked fine for me. It's 51 & 52, and the problem is frustratingly intermittent.

@mo, bedney..

Alright guys. We're having some trouble reproducing this bug. We'll need some help here.

Since it appears that things are fixed in 53, we're trying to find the commit that fixed things, so we can merge it to 52 beta. (Before 52 ships to stable)

We'd like your help bisecting to the perf fix that landed between 51/52 and 53.

The full docs are here: https://www.chromium.org/developers/bisect-builds-py

But here's the basics:

# get the bisect builds script
curl -s --basic -n "https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT" | base64 -D > bisect-builds.py

# run it
python tools/bisect-builds.py -a mac -g <goodrev> -b <badrev> --use-local-cache -- --no-first-run --user-data-dir=/tmp http://example.com

To start with we should probably use these revisions
good rev: 403382 (m53 dev channel right now)
bad rev: 394939 (m52 beta channel)

If 394939 ends up being OK, then you can try stable's rev for bad: 386251

Bisect builds will get chromium builds for you. If it performs fine, mark as Good. Hopefully you'll zero in on a commit range that we can work with. 

Good luck!

If you can no longer repro on 52 nor 53, it sounds like what people are seeing is  issue 622810 . It was fixed in Canary, merged to 53 a couple of days ago. I'm going to merge to 52 soon. 52 is likely to require manual merge though.

> If you can no longer repro on 52 nor 53,

You say this, but then a sentence later you say the fix isn't merged to 52 yet. :) Bedney above sees 52 is slow and 53 is fast. So that's on track.

Hopefully mo and carlos can confirm that 52 is slow and 53 is fast. If that's the case, we're done after the 622810 merge. :)

Sorry, wrong numbers, I meant "53 nor 54". Merged to 52 last night so the next 52 should have the fix too.

Frustratingly, I can no longer reproduce the behavior on Chrome 51, even. For what's worth, it's fast on 52 *and* Canary as well. But clearly this new test shouldn't be trusted.

We're in the  middle of code release so I haven't had time to go thru the instructions.   I'm ding all my debugging in Canary.  51.X is still sluggish.

#632372 may be relevant here

https://bugs.chromium.org/p/chromium/issues/detail?id=632372&q=snippets&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

Is this still relevant? There was no new input for a while.

Just updated to Version 52.0.2743.82 (64-bit).  Sluggish as ever.  

Canary works fine for me (Version 54.0.2811.0 canary (64-bit)) although I've noticed unrelated issues.

Apologies, I haven't had time to zoom into the build yet (#32)...deep in release.

(#32): my bisect build result shows the sudden drop in performance happened between builds: 

- g 397893  -b 397886 (no intermediary builds found by bicect)

So there it is.  Sorry for the delay and I hope this helps.

Mo

@szager: your commit https://crrev.com/1930183002 seems to be the only suspicious one, given that we rely heavily on flexbox in devtools. Could it be the reason of performance regression? 

The bisect range identified in comment #41 is from M53, none of those commits are in M52.

My change did in fact cause some flexbox performance regressions, but the fix is already in M53:

https://codereview.chromium.org/2088323003

So, while the bisect may be accurate, it doesn't explain the slowness in M52.

Might be  issue 600334 .

 Issue 637549  has been merged into this issue.

Basically dev tools has been sluggish for a while.  I did go thru effort of bisecting, as instructed, however, engagement mostly stopped after that.  

I'll just add my observations as a data point.

Under version 52 both the source debugger and dom inspector were unusably slow.
With the update to 53, the source debugger has improved significantly to the point that it is at least tolerable (not great, but usable).  However, the dom inspector is still useless.

Sure hope this gets fixed soon.

Could it be that you enabled Accessibility support in Chrome?

@ #48: Correct, currently Chrome is, and has been for a while, less than usable as a platform development tool.  

Everyone: please, follow instructions in comment #32 to help us find the root cause.

Also, providing as much details as possible would help: 
- did you try running chrome with clean profile?
- does it happen on literally every website, including about:blank?
- which mac do you use (air/pro/new mac, which year)?
- do you have chrome://accessibility/ on?

It is serious in the window. As with the Mac.
Try comparing the same page with firefox.
Chrome is impossible to even see the open dom.
This has slowed down for a long time.
43 or earlier will still be available.
Chrome developer tools are too slow recently.
55 was slightly improved.
But still slow compared with firefox.

@everyone: we won't be able to address it unless we can repro it. Could you look at comment #52 and answer the questions there? Most importantly, can you make sure accessibility is turned 'off' under chrome://accessibility?

Accessibility is off for me, and it's still sluggish as of 52.0.2743.116 on OS X.

But I now have a publicly available webpage that triggers this issue consistently for me: https://cscheid.net/courses/fal16/cs444/lectures/lecture5/colors.html

Open developer tools, switch to "sources", open the terminal. Try typing the expression "d3.scaleLinear". Each character takes about half a second here.

#55 - works fast for me, using Chrome 53 on Windows (you might want to update your Chrome, since you use Chrome 52 which still has the bug mentioned in comment 43). I even manually opened main.js in the editor of the Sources panel and typed in the console - still fast.

UPDATE:  Works:  Version 53.0.2785.101 (64-bit), OSX:10.10.5

Note, because of the lack of usability of previous versions (sluggishness of dev tools interactivity) I had moved on to Canary for development. This seems to have inhibited Chrome update. As soon as I killed Canary the failing Chrome update completed successfully. Although, I've only worked on the updated version for a few hours, the dev tools seem to be working better and the sluggishness has either diminished or disappeared. The previous sluggish versions also worked ok for a little while but this version seems to be holding up better. I will update further if the sluggishness returns.

Using Version 53.0.2785.101 m (64-bit)

Debugging is too slow.  it was not before 52 or 51.

i don't remember correct. but some month ago(maybe 2-3) it came.

chrome beta has same thing

 

Using Version 53.0.2785.101 m (64-bit) OS : Win7

I'll concur with #56 & #58 - as of Chrome 53, this is no longer a problem for me.

Fresh install, with last version, no extension : 
Version 53.0.2785.101 m (64-bit)
The DOM inspector is laggish.
I have a huge resolution and dual screen (if it helps... 2540*1440 and 1920*1080)

I plan to downgrade to v49...

I have this problem even in 
Version 53.0.2785.116 m (64-bit)

I have tried everything. Downgraded to 47/48/49 still same problem.
Tried Canary, reinstall computer, fresh install of chrome with no profile and no extensions.

Still the developer tools lags.

I'm experiencing this issue severely as of today.

Quick video to show the lag when hovering over elements.
https://youtu.be/d7vL5eObKjo

Version 54.0.2840.87 (64-bit)
OS X Yosemite 10.10.5

jason, markusn, everyone: please, follow instructions in comment 32. We won't be able to address this unless we have an idea of what's going on.

#65 - I usually have several-megabyte JavaScript sources open that make it sluggish.

We're having this issue at my work and it's a severe development roadblock. We're literally next door to Google Fremont in Seattle so if it would help to actually see the issue in person, please contact me.

Another duplicate was merged into this.  Here's a portion of the text from the user 
"I do use 3 monitors usually, but this never used to be an issue.
Usually the Thunderbolt Apple Cinema displays.

I get the feeling this is more related to Windows and the interface with the GPU.
Disabling "Use hardware Acceleration" does not improve the issue but it does change."

 crbug.com/660986 

 Issue 660986  has been merged into this issue.

I just switched to Chrome Canary and everything is fast again.

+1 for things being fast again on Canary.  Still seems slightly slower than it used to be a couple of versions back, but it is usable!

I rely heavily on dev tools to debug and speed up development of a phonegap app (inspecting device via usb). Everything was fine bevor the update to 54.0.2840.98 some days ago (not sure what version chrome was, presumably latest stable).
For me it's not just sluggish: Today I tried to remove and readd my workspace mappings and since then the inspect window crashes when I try to open a specific css file!
Removed this from my project and everything else works like a charm... I start now to investigate what in there might cause the problems... will report.

update: as it turns out, Chrome does not like comments with more than 93.000 (!) special characters... :D
But seriously, in one of my css files a comment went rogue: a german special character ("ü") turned out to be replaced by more than 93k special-character-gibberish like "â„ÂÃâ€ÂÂ" - that's what killed my devtools.
Obviously I haven't put these in by myself. And I only worked with Chrome dev tools the last days, so the bug seems to originate from here (phonegap doesn't change the source files and sublime was closed).

#72/73: sorry for the trouble, it sounds like it's a different issue. If you could file a new bug with reproducing files/steps, that'd be greatly appreciated.

I was having the same issue for about a month and what worked for me was removing all profiles (Persons) from the browser and starting it as a fresh one.

Once I opened the browser as "Guest", the devtools got blazing fast again. Now I've added my User profile again and devtools kept as fast as "Guest".

So if you're experiencing the same issue, here are how you can fix it:
- Open a "Guest" window in Chrome (at top-right, click your name);
- Check if devtools is fast in Guest window;
- If it is, then the issue is your profile. So sign out of every profile from your browser (this may lead to history/cache loss);
- Close Chrome;
- Open again, re-login with your Google credentials;

After this "reset" devtools shall get back to working in full speed.

My devtools were laggy, especially working on a specific SPA. I tried the above post's recommendation of testing a "Guest" profile which did indeed have fast devtools. I logged out and back in of my chrome profile and my devtools appear to be fast again!

There doesn't seem to be any new reports for this.

Closing this as "fixed" for now.

I have tried the "Guest" solution with no luck. I am noticing it has something to do with rendering on the iMac (Retina 5K, 27-inch, Mid 2015) screen, when I move the main Chrome window across to a lower resolution 1080p screen, everything works normally with no CPU spikes or lag. The attached screenshot is from having dev tools opening, and resizing the main Chrome window, which is sitting within the 5k screen

Deleted: Screen Shot 2017-12-12 at 12.21.40 pm.jpg 19.4 KB

	Screen Shot 2017-12-12 at 12.21.40 pm.jpg 19.4 KB View Download

My chrome is
Version 63.0.3239.84 (Official Build) (64-bit)
My OS is OSX 10.13.11
I still have this issue.
Strange solution to dock devtools works for me. But I prefer undocked
https://stackoverflow.com/a/37885100

I got terrible performance using "inspect" on macOS High Sierra with an 27" iMac late 2015, too.

It starts good but after some seconds pass it gets worse and worse. If i close dev-tools und reopen its good again for some seconds. Also i noticed that resizing the window when dev-tools are open cpu usage gets too much. 

Deleted: Ohne Titel Kopie.png 38.3 KB

	Ohne Titel Kopie.png 38.3 KB View Download

I disabled all extensions and also tried the guest mode with no luck. I made a video here: https://youtu.be/3bM_ADA6sWs

Got this problem for month now. On my Macbook Pro it is working fine.

Also have the same problem  with freezing 
Chrome details:

Version 63.0.3239.132 (Official Build) (64-bit)

mac details: 

macOS Sierra
Version 10.12.5
iMac( Retina 5k, 27-inch, late 2015)
It works fine if i change to at least 4k resolution, but when its 5k its impossible to work with inspector.

Exact same issue for months. High Sierra. iMac 2015. Works fine on lower resolution second monitor. Tried with both Chrome and Canary. 

This issue should not be flagged as fixed. 

#84 - please, simply create new issues whenever you experience the issue instead of trying to resurrect an old issue.
Following https://www.chromium.org/developers/how-tos/submitting-a-performance-bug and attaching the results might help as well.