Closed Bug 1556813 Opened 1 year ago Closed 1 year ago

Web Replay: fast recording scanning

Categories

(Core Graveyard :: Web Replay, enhancement)

enhancement
Not set
normal

Tracking

(firefox70 fixed)

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: bhackett1024, Assigned: bhackett1024)

References

(Blocks 1 open bug)

Details

Attachments

(9 files, 3 obsolete files)

WIP
59.08 KB, patch
Details | Diff | Splinter Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
Attached patch rough WIP (obsolete) — Splinter Review

In order to support logpoints, breakpoints, and stepping, we have to scan the recording for places where each script location is hit. In order to provide a fast and convenient interface for users, we need to do this quickly, and be able to keep the scan up to date as the user interacts with the page. On an example session of debugger.html --- hit a breakpoint, step out through several frames, then wait for the scan to finish --- it can take one or two minutes after each section of recording is added for the scan of that section to complete. The attached patch brings this down to about 20 seconds. This is pretty rough and incorporates a bunch of other fixes; I'll be splitting things off into separate bugs and tidying things up shortly.

The main things this patch does are adding the Debugger instrumentation interface in bug 1554524 and integrating it with the recording scanning mechanism, and allowing lazy parsing to work when replaying --- debugger.html has 4.3 MB of JS and parsing and then instrumenting all of this up front takes several seconds, even with a bunch of instrumentation optimizations.

If I disable the logic completely, there is still a 15 second or so delay before each section of the recording has been run through by a replaying process --- they still have to both run through the recording and save checkpoints at necessary places, and having four replaying processes stresses the system a good deal. Improving this metric so that the scan can be brought up to date within a few seconds should be possible, but probably only by shifting computing resources to the cloud, where we can have fewer resource constraints.

Also, for anyone concerned, this work was done while I was on PTO / weekends, and is separate from my 'official' work at Mozilla.

Attached patch WIPSplinter Review

This is a more focused patch with just the changes associated with this bug.

Attachment #9069725 - Attachment is obsolete: true
Duplicate of this bug: 1557880
Duplicate of this bug: 1547093
Duplicate of this bug: 1547092
Duplicate of this bug: 1547089
Duplicate of this bug: 1547091

The changes in this bug are focused on providing a fast UX on complex pages like debugger.html. By leveraging the instrumentation mechanism added by bug 1554524, scanning can happen much faster than with the existing breakpoint based approach. To avoid high startup costs on these complex pages, it helps a lot to enable lazy parsing; parts 1-3 allow lazy parsing to be enabled when replaying, and for Debugger users to access scripts without delazifying them as readily (this change should benefit other Debugger users as well).

Beyond faster recording scanning, we also want to be able to update the UI quickly when navigating around within the recording. Pause data at messages (both console messages and logpoints), potential breakpoint hits, and potential steps are gathered, including the graphics to show at that point, and then used to update the UI immediately when the user navigates. When the navigation occurs, we start sending a replaying process to the point being navigated to, but the UI can fully update (if there aren't any watched expressions) before the replaying process reaches its destination. This leads to a much faster experience when replaying, as long as things are working smoothly. There are some UI tweaks to show unscanned regions of the recording and console messages which pause data hasn't been gathered for, which should help for now at least until things get more testing and remaining issues are ironed out.

Attachment #9072049 - Attachment is obsolete: true
Attachment #9072048 - Attachment is obsolete: true
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/93d5840653ae
Part 1 - Allow lazy script parsing when recording/replaying, r=jandem.
https://hg.mozilla.org/integration/mozilla-inbound/rev/e4bd68b4094b
Part 4 - Add Debugger API to create native functions in a debuggee's realm, r=jorendorff.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1d6fad7467b
Part 5 - Server changes for instrumentation based control logic, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/40744b3611a5
Part 6 - Watch for provisional logpoint messages in webconsole, r=nchevobbe.
https://hg.mozilla.org/integration/mozilla-inbound/rev/9a6171df1f78
Part 7 - Instrumentation based control logic, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/fce998a05369
Part 8 - C++ changes for instrumentation based control logic, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/eeeab13f3b16
Part 9 - Show unscanned regions and uncached points on timeline, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/6e0c40509959
Part 10 - Add test for breakpoint hits with complex control flow, r=loganfsmyth.
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7445556b1e0e
Part 1 - Allow lazy script parsing when recording/replaying, r=jandem.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ca1cc1b8d9e2
Part 4 - Add Debugger API to create native functions in a debuggee's realm, r=jorendorff.
https://hg.mozilla.org/integration/mozilla-inbound/rev/fbd4e75a3d1b
Part 5 - Server changes for instrumentation based control logic, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/6bee529b3fb0
Part 6 - Watch for provisional logpoint messages in webconsole, r=nchevobbe.
https://hg.mozilla.org/integration/mozilla-inbound/rev/4006b5658fdf
Part 7 - Instrumentation based control logic, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/e6c585a81acf
Part 8 - C++ changes for instrumentation based control logic, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/0ebf590f9384
Part 9 - Show unscanned regions and uncached points on timeline, r=loganfsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/58221fa751ac
Part 10 - Add test for breakpoint hits with complex control flow, r=loganfsmyth.
Flags: needinfo?(bhackett1024)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.