1239473 - Stepping in debugger gets very slow with complex scripts and deep stacks

Status: RESOLVED WONTFIX

(DevTools :: Debugger, defect)

Description

[Hallvord R. M. Steen [:hallvors]]

I've long been frustrated by the debugger sometimes being slow when used for real-life tasks with complex scripts. The test I've been developing for bug 1154874 seems to prove that there is a reproducable, measurable slowdown when the stack grows. 

It would be great to have some optimisations done here!

Comment 1

[Hallvord R. M. Steen [:hallvors]]

(By "very slow" I mean a lag of 0.5 - 2 (!) seconds for each "Step into" ([F11]) - this is maddening if you're trying to get a quick overview of how some code runs)

Comment 2

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

(In reply to Hallvord R. M. Steen [:hallvors] from comment #1)
> (By "very slow" I mean a lag of 0.5 - 2 (!) seconds for each "Step into"
> ([F11]) - this is maddening if you're trying to get a quick overview of how
> some code runs)

Can you use the browser toolbox to collect a performance profile while reproducing this issue and upload it here?

Comment 3

[Hallvord R. M. Steen [:hallvors]]

Attachment: debugger-stepping-profile.json

Here's some data, captured when stepping manually in the bug 1154874 test with a pretty deep stack. I noticed significantly better performance when the devtools pane was docked to the side of the window rather than underneath. There's probably some data for each configuration in this json file.

Comment 4

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

(In reply to Hallvord R. M. Steen [:hallvors] from comment #3)
> Created attachment 8708267 [details]
> debugger-stepping-profile.json
> 
> Here's some data, captured when stepping manually in the bug 1154874 test
> with a pretty deep stack. I noticed significantly better performance when
> the devtools pane was docked to the side of the window rather than
> underneath. There's probably some data for each configuration in this json
> file.

Interesting. pullTimelineData seems to be transitively taking a huge chunk of the time here (see the flame view), which is overhead caused by the act of profiling... Seeing pauses on the order of 200-1000ms... not good :-/

Jordan, Victor: any idea how we can make pullTimelineData faster, or do less work, or do it less often, or something? This is p bad IMO.

I am also seeing some pauses from StackFrames.prototype._afterFramesCleared and StackFramesView.prototype.selectFrame, et al in debugger-controller.js but these are on the order of 50-100ms, which is also pretty bad but pales in comparison to the above.

Comment 5

[Jordan Santell [:jsantell] [@jsantell]]

Looks like pullTimelineData, the function that gathers fresh markers from docshell, is mostly spending its time in StackFramesView.prototype.makeEvent (iterating over the array?) -- lots of `values`, `CreateArrayIterator`, and `next` functions underneath that, self-hosted, so guessing it's something with that loop.

This is a very marker heavy profile -- all the more reason to introduce non-realtime markers, because the overhead just gets more costly.

Comment 6

[Hallvord R. M. Steen [:hallvors]]

I'm curious if the debugger adds elements for everything in the stack to the DOM when it's in "landscape mode" and you have the "bread crumb"-style strip of stack frame history.. If it does it would probably explain some of the slowness and the difference between docking the debugger at the bottom ("landscape mode") and right ("portrait mode").

Comment 7

[Victor Porof [:vporof][:vp]]

Agree with Jordan said. Maybe we should just bite the bullet and accept the fact that realtime markers cost too much with little benefit.

Comment 8

[Jason Laster [:jlast]]

Is this an issue for the debugger in general or only when it's profiling?

Comment 9

[Jason Laster [:jlast]]

closing as this is related to the old debugger.