Closed Bug 1537779 Opened 5 years ago Closed 5 years ago

Improve column breakpoint UI performance

Categories

(DevTools :: Debugger, defect, P1)

defect

Tracking

(firefox68 fixed)

RESOLVED FIXED
Firefox 68
Tracking Status
firefox68 --- fixed

People

(Reporter: jlast, Assigned: jlast)

References

(Blocks 1 open bug)

Details

(Whiteboard: [debugger-mvp][devtools-backward-compat])

Attachments

(2 files)

I noticed while profiling debugger.html that getColumnBreakpoints takes awhile for debugger.html profile

The reason looks like getSelectedLocation, which calls isOriginalId.

STR:

  1. go to localhost:8000
  2. select debugger.js
  3. add some breakpoints
  4. reload...

Another hot spot, which comes from jryans' app is filterByUniqLocation profile. I assume this must happen if you get a lot of breakpoint positions back.

Summary: getColumnBreakpoints can be ~100ms → Improve column breakpoint UI performance

Another hot spot in debugger.html is findEmptyLines profile,

  • this also looks related to getSelectedLocation.
  • the split takes awhile
Priority: -- → P1
Has STR: --- → yes

After looking into this a bit, i'm seeing a couple of things:

  1. using a synchronous getOriginalLocation will have a nice impact (1.8sec --> 450ms) old --> new
  1. memoizing URL parsing in source-map saves 200ms (475ms --> 287ms) . old --> new (PR)
  1. sending the packet of 80K locations to and from the worker is slow...
  2. supporting 80K locations in other UI elements is slow...
  3. the UI feels much snappier after the first two fixes
Pushed by jlaster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ff20472890a1
Improve column breakpoint UI performance. r=loganfsmyth
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
Assignee: nobody → jlaster
Pushed by jlaster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0ec8134b1b62
Improve column breakpoint UI performance. r=loganfsmyth
Whiteboard: [debugger-mvp]

When connected to an older server, the call to getBreakableLines fails:

"Action loadSourceText had an exception:" 
  "Protocol error (unrecognizedPacketType): 
   Actor server1.conn2.child9/source23 does not recognize the packet type getBreakableLines"

What can be the impact of this for a debugging session, should we address it?

Edit: discussing with Yulia, one of the possible regressions linked to this is that all lines appear greyed out as if we couldn't set breakpoints on them. Anything else?

Flags: needinfo?(jlaster)
Whiteboard: [debugger-mvp] → [debugger-mvp][devtools-backward-compat]
Flags: needinfo?(jlaster)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: