987951 - DebuggerServer.addChildActors() taking 1 second on 'The Weather Channel' startup

Status: RESOLVED WORKSFORME

(DevTools Graveyard :: WebIDE, defect)

Description

[Benoit Girard (:BenWa)]

DebuggerServer.addChildActors() @ main.js:371 is dominating the startup time of 'The Weather Channel' app.

STR:
1) Install the 'The Weather Channel' app.
2) Run and select your default city, close the app
3) Run the app without wifi

http://people.mozilla.org/~bgirard/cleopatra/#report=41a790b5b41c4abe3003da625d3fcb5f11acbc8c

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

This appears to be the main cause for the slow startup recorded in the blocker bug 985170.

Comment 2

[Alexandre Poirot [:ochameau]]

I do not see any reference to the app manager in the STR, but tell me you are using it to launch the app!? DebuggerServer.addChildActors shouldn't ever be called unless you are using devtools,
I hope we are not seing it be called in production code!

For now, we never really focused on memory/cpu usage of devtools codebase on device, so I'm pretty sure we can improve things here.

I imagine that using the app manager will introduce some noise in the profiling and may disallow easily figure out why this app is slow without devtools...

Comment 3

[Benoit Girard (:BenWa)]

Should of been more specific that I'm seeing this overhead without using the devtools.

(In reply to Alexandre Poirot (:ochameau) from comment #2)
> I do not see any reference to the app manager in the STR, but tell me you
> are using it to launch the app!?

No I'm not using app manager, this is the wrong component but there isn't a component for 'Debug Server' AFAIK. It seemed like the best approximate component of the debug server on b2g component.

> DebuggerServer.addChildActors shouldn't
> ever be called unless you are using devtools,
> I hope we are not seing it be called in production code!

We are seeing this I have the 'Remote Debugging' set to 'ADB only'. I cleared my profile today so it's relatively clean.

Comment 4

[Alexandre Poirot [:ochameau]]

Oh wait, you can also trigger this code when using Developer HUD. Do you have it enabled by any chance?

Anyway, I'll take a look at this tomorrow.

Comment 5

[Benoit Girard (:BenWa)]

No, it was set to 'ADB only', I have a new b2g profile.

Comment 6

[Alexandre Poirot [:ochameau]]

I'm not able to reproduce it on master without turning devtools on, or the Developer HUB (the colorful counter displayed at app bottom right).

I'll try to test that on 1.4 a bit later.

Comment 7

[Benoit Girard (:BenWa)]

I was testing on master.

Comment 8

[Alexandre Poirot [:ochameau]]

Are you really sure you don't have any Developer HUD counter enabled?
  These error, reflow, janks, startup time, ... counters:
  http://paulrouget.com/e/fxoshud/

I'm trying to ensure I get profiler data right:
  http://people.mozilla.org/~bgirard/cleopatra/#report=41a790b5b41c4abe3003da625d3fcb5f11acbc8c

In both processes I see epoll_wait first. Is it something to always ignore? Is it just the event loop?

Then comes addChildActors that takes 116ms to run, which seems really short given the report on bug 985170? Or is it just running faster on your device?

Otherwise without even looking at profiler results, I'm pretty confident bug 988237's patch will greatly improve addChildActors performances.

Comment 9

[Benoit Girard (:BenWa)]

I did have the developer HUD for the FPS counter, which is a cheap OpenGL side counter (bypassing most of the rendering pipeline).

Comment 10

[Jason Smith [:jsmith]]

Looks like this isn't directly related to bug 985170 - we're not seeing the perf regression anymore after the dupe of that bug landed.

Comment 11

[Jason Smith [:jsmith]]

Clearing regression keyword cause I'm unsure if we've proven this is a regression now.

Comment 12

[Benoit Girard (:BenWa)]

Well we can no longer use the FPS counter without affecting performance because it now requires the developer HUD (even if the code is unrelated) which makes the feature useless. So yes we've regressed the FPS counter.

Comment 13

[Alexandre Poirot [:ochameau]]

Yes, that's an unexpected regression. Jan, would you have some cycle to tweak that?

Otherwise, Devtools codebase shouldn't be so aggressive on using cpu cycles and memory.
I'll try to spend some cycles on devtools performances on devices.
Bug 988237 should be a very good first step.

Comment 14

[Jason Smith [:jsmith]]

Ok - re-adding the regression keyword then.

Comment 15

[Jan Keromnes [:janx]]

The `addChildActors` slowness is caused by the Developer HUD being active, and currently you need to have it active to enable the FPS counter, which is my fault for putting the setting there.

When the Developer HUD is active, it listens for all frames being created with an appManifestUrl, and instruments them by calling `addChildActors`.

You can work around this false dependency by activating the Developer HUD, enabling the FPS counter, and disabling the Developer HUD again. The FPS counter, not being integrated yet, will stay on.

The better long-term solution will be to reduce the instrumentation footprint of the Developer HUD, and as Alex said, bug #989263 would be a great first step. In the mean time, freeing the FPS and TTL monitor settings from the main Developer HUD setting again should better reflect their independence. I filed bug #989272 for that.

Comment 16

[Preeti Raghunath(:Preeti)]

Request aurora approval here. will not block release on the same

Comment 17

[joseenrique.alvarezfernandez]

From what I understand seems that this is not a bug on TWC side, is it?

Please confirm as TWC requested it

Comment 18

[Benoit Girard (:BenWa)]

It's not, it's a bug with our tools.

The FPS counter can now again be activated without turning on the debug actor. I'll close this bug. I suspect that some of the developer HUD still have a large performance impact when activated however.

WFM since this was fixed in another bug.