1003664 - High CPU usage just opening and browsing in debugger.

Status: RESOLVED FIXED

(DevTools :: Debugger, defect)

Description

[Luke]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140410213615

Steps to reproduce:

Opened debugger on a page (any page, this should work: https://startpage.com/do/search)


Actual results:

CPU is at the usual 0 or 1 percent, but when debugger is opened, just looking around and not stepping, takes at least 10% constantly (100% being all 4 cpus in Ubuntu System monitor)

The same thing happens in Firefox safe-mode.


Expected results:

It shouldn't use half a cpu for no reason when the debugger is open.

Comment 1

[sjw]

Maybe related with bug 946336?

Comment 2

[Luke]

Thanks, but No, I don't even have CSS checked - it happens when the debugger tab is open.

Comment 3

[Cornel Ionce [:noni] [Hubs QA]]

Confirming this issue on Fx 29, build ID: 20140410213615 and latest Nightly, build ID: 20140504030205.

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Can confirm on Nightly 32 as well.

Comment 5

[Luke]

This is annoying - is there any config option that will make it use less cpu when the devtools are open?

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Luke from comment #5)
> This is annoying - is there any config option that will make it use less cpu
> when the devtools are open?

Not specifically.  We'd likely need to isolate what makes this happen on this page specifically.

Do you have add-ons installed?  Another user saw a similar high CPU debugger issue and they tracked it down to one of their add-ons.  You can check this by trying a temporary profile or disabling your add-ons as a test.

Comment 7

[Merike Sell (:merike)]

I'm also seeing high cpu usage whenever I connect to Thunderbird's main process and open the debugger. Usually about 60% cpu without doing anything else. When I switch back to console it goes to 100%. This happens even when the Firefox profile I use for debugging has no enabled extensions and when I connect to a new Thunderbird profile that has nothing set up.

Comment 8

[Luke]

Same here, I had also noticed it in Firefox safe-mode, that is, no extensions.

Comment 10

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Jim, might this be in the JS engine's Debugger API?

Here's the STR from duplicate bug 1138102, which is a bit more specific:

1. go to a simple page (like about:blank or http://everlong.org/).
2. open your CPU use monitor (eg: top on Linux). Observe the CPU usage is very low.
3. open the dev tools using ctrl-shift-k. Observe the CPU usage is still low.
4. switch to the Debugger tab. Observe the CPU usage is big (steadily ~35-45% on my computer).
5. observe that the CPU usage does not change even when you do nothing at all in Firefox.
6. close the dev tools, observe that the CPU usage drops back to a normal value.

:julienw from Gaia team is able to reproduce and is happy to help test a change.

Comment 11

[Jim Blandy :jimb]

This would be a nice test case for chrome profiling. Do we support that yet?

Comment 12

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Jim Blandy :jimb from comment #11)
> This would be a nice test case for chrome profiling. Do we support that yet?

The builtin profiler doesn't symbolicate C++, so it is fairly useless for this case. https://bugzilla.mozilla.org/show_bug.cgi?id=1132529

Would suggest either the addon+cleopatra or just using your OS's builtin profiling tools.

Comment 13

[Alexandre Poirot [:ochameau]]

While looking at bug 1142623 I identified various slowness due to the Debugger.
It looks like really simple slowdown due to SourceActor. I'm not sure the platform code is involved much in this (i.e. I'm not sure Debugger object/API is to blame here).
It sounds more like client<->server code being inneficient when registering new scripts.
See bug 1142623 comment 9.

Regarding profiler, the profiler from the browser toolbox gives us some hints.
But I was mislead by its results... It was telling me mapURItoAddonID was the main culprit whereas it wasn't :x

Comment 14

[Geoff Lankow (:darktrojan)]

I've this discovered in debugger.xul:

> <progressmeter id="source-progress" mode="undetermined"/>

Even though it can't be seen it's spinning constantly and causing lots of flushing and painting events. I think it's at least partially responsible for this bug.

Comment 15

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: Use an html instead of a xul progress bar for better perf on Linux

That was an amazingly helpful discovery! Switching to an HTML progress element seems to not have that performance impact on Linux in my testing. Geoff, can you confirm it on your system?

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Geoff Lankow (:darktrojan) from comment #14)
> Even though it can't be seen it's spinning constantly and causing lots of
> flushing and painting events.

Do you think you could spin up a standalone testcase that reproduces this? (with pref " dom.allow_XUL_XBL_for_file" enabled, to let you load XUL testcases)

If so: please file a bug in Core|Layout, with the testcase -- this is probably something we should look into.

Comment 17

[Julien Wajsberg [:julienw]]

bug 962594 could be related.

Comment 18

[James Long (:jlongster)]

Comment on attachment 8579988 [details] [diff] [review]
Use an html instead of a xul progress bar for better perf on Linux

Review of attachment 8579988 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/debugger/debugger.css
@@ +50,5 @@
>  }
> +
> +#source-progress-container {
> +  display: -moz-box;
> +  -moz-box-pack: center;

Any reason to use this over the more modern flexbox?

Comment 19

[Geoff Lankow (:darktrojan)]

(In reply to Daniel Holbert [:dholbert] from comment #16)
> (In reply to Geoff Lankow (:darktrojan) from comment #14)
> > Even though it can't be seen it's spinning constantly and causing lots of
> > flushing and painting events.
> 
> Do you think you could spin up a standalone testcase that reproduces this?
> (with pref " dom.allow_XUL_XBL_for_file" enabled, to let you load XUL
> testcases)
> 
> If so: please file a bug in Core|Layout, with the testcase -- this is
> probably something we should look into.

I've filed bug 1145406 in Toolkit|XUL Widgets instead, since it's the widget itself that's causing the problem.

Comment 20

[Geoff Lankow (:darktrojan)]

Comment on attachment 8579988 [details] [diff] [review]
Use an html instead of a xul progress bar for better perf on Linux

Yup, that fixes it.

Comment 21

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: Use an html instead of a xul progress bar for better perf on Linux v2

(In reply to James Long (:jlongster) from comment #18)
> Any reason to use this over the more modern flexbox?

Just that I couldn't make it as concise, but happy to use that if you prefer.

Comment 22

[James Long (:jlongster)]

Comment on attachment 8581527 [details] [diff] [review]
Use an html instead of a xul progress bar for better perf on Linux v2

Review of attachment 8581527 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for tweaking that! I think it's good to use the standard flex when possible now.

Comment 23

[Daniel Holbert [:dholbert]]

Comment on attachment 8581527 [details] [diff] [review]
Use an html instead of a xul progress bar for better perf on Linux v2

Drive-by observation:

>+.spacer {
>+  flex: auto;
>+}
[...]
>+        <html:div id="source-progress-container"
>+                  align="center">
>+          <html:div class="spacer"></html:div>
>+          <html:div id="hbox">
>+            <html:progress id="source-progress"></html:progress>
>+          </html:div>
>+          <html:div class="spacer"></html:div>

Are the "spacer" divs just being used for centering 'source-progress' here? If so, "justify-content:center" on source-progress-container is a more declarative & performant way to achieve that result.

(With the spacer divs right now, we have to reflow them to establish their "auto" height, to honor your requested "flex:auto" -- which is cheap since they're empty, but it's still extra reflowing that could be avoided.)

Comment 24

[Daniel Holbert [:dholbert]]

(specifically, I'm wondering if we can *remove* the spacer divs, and use "justify-content:center" instead)

Comment 25

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Daniel Holbert [:dholbert] from comment #23)
> Are the "spacer" divs just being used for centering 'source-progress' here?
> If so, "justify-content:center" on source-progress-container is a more
> declarative & performant way to achieve that result.

Oh, that's good to know. That's exactly why I used the spacer divs and I'll happily take them out now.

Comment 26

[Panos Astithas (he/him) [:past] (please ni?)]

https://hg.mozilla.org/integration/fx-team/rev/15403c96b0d4

Comment 27

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/15403c96b0d4

Comment 28

[porjo38]

I'm having this issue with Firefox 41.0 on Linux. A blank profile (no extensions) makes no difference. CPU on my laptop sits around 40-50% usage while the developer tools are open. When I close them, CPU usage drops right back.

Comment 29

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to porjo38 from comment #28)
> I'm having this issue with Firefox 41.0 on Linux. A blank profile (no
> extensions) makes no difference. CPU on my laptop sits around 40-50% usage
> while the developer tools are open. When I close them, CPU usage drops right
> back.

Since it's been a while since this bug resolved, it would be best to file a new bug about your issue so we can track it appropriately.

Comment 30

[porjo38]

OK, thanks. I've created bug #1209784 now