1122483 - Having the Browser Console or Web console open dramatically slows down the performance of the browser

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[Mark Banner (:standard8)]

STR (Hello Call):

1) Set up two browsers ready for a hello call between both of them (I've tested on fx-team debug builds and Firefox nightly opt builds, with both running on a single Macbook Pro).
2) On the browsers, set all the loop.debug.* to true (or "All" in the case of loop.debug.loglevel)
4) Start a call (I was using a direct call, but you should see this with rooms as well) and watch the responsiveness
5) End the call
6) Open the browser console on each browser
7) Now start, setup and end several calls.

=> Responsiveness of call setup becomes sluggish, takes longer to set up local media and connect the call.

8) End any call, close the browser consoles
9) Start a new call

=> Responsiveness is back to what it originally was.

I've seen this sort of effect on various pages, including our ui-showcase and unit tests at times, though its unclear if they are the same issue or not.

Comment 1

[Mike de Boer [:mikedeboer]]

Isn't this kind of expected, though? I mean, we don't have a really nicely optimized console logger - with a virtual viewport that appends only the nodes that ought to be visible and lazy, batched appending - so degraded perf with a lot of log spew is expected behavior for me at this point.

Comment 2

[Mark Banner (:standard8)]

I would expect some degraded perf, but the issue is it becomes painfully slow. Call setup times etc just take forever, and in the past when we've had timeouts, meant we've hit the 10 or 20 second timeouts.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

The real problem here, for me, is that it causes me to write and debug unit test pages with the console closed, which means that I sometimes don't see important warnings/errors (both in test and implementation code) when I introduce them (if at all), which is a frustrating workflow inefficiency.  

If this is a common problem for web developers (which I suspect it is), and if Chrome does better (not sure about this), this encourages web dev users to feel like they end up with better code if they primarily write/test using Chrome.

Comment 4

[Alexandre Poirot [:ochameau]]

We don't have super smart viewport mechanism, but I think there is some regression, or at least various details to easily tweak in order to get better performances!
I'm currently trying to gather the various console performances issues on bug 1156747.

Comment 5

[Brian Grinstead [:bgrins]]

(In reply to Mark Banner (:standard8) from comment #2)
> I would expect some degraded perf, but the issue is it becomes painfully
> slow. Call setup times etc just take forever, and in the past when we've had
> timeouts, meant we've hit the 10 or 20 second timeouts.

I did a quick check with the Hello tests at http://localhost:3000/test/shared/ and when the Console panel was opened it was definitely slower.  After some profiling it seems there are still issues in _flushMessageQueue (while trying to keep the output scrolled to the bottom as new messages come in), among other places.  I did some work in bug 1045715 to improve this, but it still needs some work.

But I wouldn't expect 10 or 20 second timeouts due to this (although maybe if you are running a debug build).

Comment 6

[Brian Grinstead [:bgrins]]

Attachment: console-stress-test-profile.json

New profile on http://bgrins.github.io/devtools-demos/console/stress.html using latest console and latest perf tools on a clean profile with e10s enabled

Comment 7

[Brian Grinstead [:bgrins]]

Mark, Dan, can you please let me know if you are still seeing this?  I've recently made some progress on console perf in Bug 1237368 and when running the same Hello tests in Comment 5 I'm not seeing much of a slowdown anymore.  If you have a specific STR where you are still seeing this please let me know.

Comment 8

[Mark Banner (:standard8)]

Sorry for the delay. I've just tried this on my Macbook Pro, 10.10.

For our shared tests, without the console open, I'm seeing about 5s time to run the tests in both non-e10s and e10s mode.

In e10s mode with the console open, it remains around the 5s time.

In non-e10s mode with the console open, its still doubling to about 10/11 seconds.

Comment 9

[Brian Grinstead [:bgrins]]

(In reply to Mark Banner (:standard8) from comment #8)
> Sorry for the delay. I've just tried this on my Macbook Pro, 10.10.
> 
> For our shared tests, without the console open, I'm seeing about 5s time to
> run the tests in both non-e10s and e10s mode.
> 
> In e10s mode with the console open, it remains around the 5s time.
> 
> In non-e10s mode with the console open, its still doubling to about 10/11
> seconds.

Thanks for the response.  Glad to hear there's pretty much no slowdown on e10s - that might be enough to close the bug since e10s is shipping by default on Dev Edition.  But, can you point me to some docs or STR for running these tests so I can profile and see if there's anything obvious going on in non-e10s?

Comment 10

[Mark Banner (:standard8)]

Yep, the easy way is to clone:

https://github.com/mozilla/loop

You can then do:

- make build
- make runserver

Then load http://localhost:3000/shared/test/index.html in the browser.

Comment 11

[Brian Grinstead [:bgrins]]

I'm seeing really similar results as reported in Comment 8 (around 2x slowdown without e10s and approximately the same time with e10s).  The profile I took is not showing webconsole frontend code anywhere near the top, which is gratifying.  In fact, I see a similar slowdown when I open just the inspector panel so this might be overhead of attaching to the thread actor.  Since Dev Edition is shipping e10s I'm going to close this one out.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Thanks, Brian!