Bug 156250

<rdar://problem/25561452>

The protocol traffic from the DOM agent is starving things. You basically can't do anything in the Inspector with this much protocol traffic. We should look at coalescing the DOM agent events. Note: Chrome Canary DevTools hang worse for me. I can't even type in the Console there. If you start on Console in Chrome, you are fine. But if you ever show the Elements panel, and later switch to Console is hangs. I can type in Safari Web Inspector, just without autocomplete results, or anything happening quickly after pressing enter.

Honestly this repro is more of a generic stress test. Did you see the effect I mentioned where the lag is only introduced after switching inspector tabs?

Yes, switching tabs does have an effect in Web Inspector. The effect is much worse in Chrome Dev Tools. We should fix this. In general any where the page is busy, that causes a lot of Inspector protocol traffic, which makes it hard to do any outgoing commands. Also it taxes the CPU and starves the Web Inspector process.

We did some performance work for this. Please reopen if you find pages that stall out still (and are not stupid microbenchmarks).

Thanks Brian. Just to clarify: is the "Simple test page" attached to this ticket an example of a stupid microbenchmark? (Totally frank question, keen to learn what constitutes a useful repro).

(In reply to comment #6) > Thanks Brian. Just to clarify: is the "Simple test page" attached to this > ticket an example of a stupid microbenchmark? (Totally frank question, keen > to learn what constitutes a useful repro). I hate to be dismissive, but unfortunately yes :(. I was using d3 SVG animations (from d3 gallery) as a more realistic test case that does spam attribute changes. In trunk it is not silky smooth but it's usable at least. If you find otherwise, then there is cause to optimize it further.

Ok, that's useful to know. The original case that led to this ticket was an ember app that slowed down noticeably with the inspector open (it still does) but I figured there was way too much noise to be useful so whittled it down to something minimal that still demonstrated the particular issue.

(In reply to comment #8) > Ok, that's useful to know. The original case that led to this ticket was an > ember app that slowed down noticeably with the inspector open (it still > does) but I figured there was way too much noise to be useful so whittled it > down to something minimal that still demonstrated the particular issue. Performance here also depends on the distribution of attribute updates to DOM elements, how often elements are added/removed, how many different properties are being changed, etc. It would probably be better to start with the real world example so that I can capture some of these properties before trying to optimize our implementation.

Just a note that the issues I described previously match those described here: https://bugs.webkit.org/show_bug.cgi?id=158117