Disable debugger while a performance profile is actively recording

NEW
Unassigned

Status

()

Firefox
Developer Tools: Debugger
P2
normal
2 years ago
2 years ago

People

(Reporter: fitzgen, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

In bug 1274097, we found that at least 25% of time in a profile was attributed to the debugger, because it is always on. This is problematic for two reasons:

1. It is contributing a large slowdown: about 12 or 13 seconds altogether.

2. It skews performance results (especially when profiling without show-gecko-platform-data and you think that this time is attributed to your code!) and makes them unreliable.

We need to have the parent (tab, worker, chrome, ...) actor emit "start-profiling" and "stop-profiling" events and automatically enable and disable the Debugger instance (or attach and detach the ThreadActor?) respectively.
At some point, we should profile the ThreadActor and see what is causing so many collections. Or just why it's slow generally. I don't see why we can't make the debugger server itself pretty cheap. But that's for another day.

Is that test case allocating a bunch of scripts, therefore stressing the debugger server? I'm assuming so, as otherwise the debugger shouldn't interact much with the page.

But this is a good idea generally. The perf tool should never be affected by the debugger, whether or not we have a perf problem with it. I would like to figure out how we can optimize the server though so web pages don't suffer the same perf problems.
(In reply to James Long (:jlongster) from comment #1)
> At some point, we should profile the ThreadActor and see what is causing so
> many collections. Or just why it's slow generally. I don't see why we can't
> make the debugger server itself pretty cheap. But that's for another day.

I attached a profile to bug 1274097 which should have enough samples to find something interesting. You can import it locally.

Also would be good to get a DAMP test for evaluating a crap ton of sources with many scripts in the debuggee.

> Is that test case allocating a bunch of scripts, therefore stressing the
> debugger server? I'm assuming so, as otherwise the debugger shouldn't
> interact much with the page.

Seems like a sound assumption, but I didn't look into it. You can follow bug 1274097's STR if you'd like to dive in.
This looks like a feature request that we should look into some time soon. Assigning P2.
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.