Web Replay: fast recording scanning
Categories
(Core Graveyard :: Web Replay, enhancement)
Tracking
(firefox70 fixed)
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: bhackett1024, Assigned: bhackett1024)
References
Details
Attachments
(9 files, 3 obsolete files)
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 |
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.
Assignee | ||
Comment 1•6 years ago
|
||
Also, for anyone concerned, this work was done while I was on PTO / weekends, and is separate from my 'official' work at Mozilla.
Assignee | ||
Comment 2•6 years ago
|
||
This is a more focused patch with just the changes associated with this bug.
Assignee | ||
Comment 3•6 years ago
|
||
Assignee | ||
Comment 4•6 years ago
|
||
Depends on D34961
Assignee | ||
Comment 5•6 years ago
|
||
Depends on D34962
Assignee | ||
Comment 6•6 years ago
|
||
Depends on D34963
Assignee | ||
Comment 7•6 years ago
|
||
Depends on D34964
Assignee | ||
Comment 8•6 years ago
|
||
Assignee | ||
Comment 9•6 years ago
|
||
Depends on D34966
Assignee | ||
Comment 10•6 years ago
|
||
Depends on D34967
Assignee | ||
Comment 11•6 years ago
|
||
Depends on D34968
Assignee | ||
Comment 12•6 years ago
|
||
Depends on D34969
Assignee | ||
Comment 18•6 years ago
|
||
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.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 19•6 years ago
|
||
Comment 20•6 years ago
|
||
Backed out 8 changesets (Bug 1556813) for xpcshell and devtool failures at test_logpoint-01.js.
Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/e701db72ceb7657fd92f5ffbf392ab79feb6e8aa
Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=6e0c40509959c77b447328b45768d815f951f81d&selectedJob=258702561
Failure log:
Xpcshell:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=258702561&repo=mozilla-inbound&lineNumber=4263
Devtool:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=258702301&repo=mozilla-inbound&lineNumber=10095
Comment 21•6 years ago
|
||
Comment 22•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7445556b1e0e
https://hg.mozilla.org/mozilla-central/rev/ca1cc1b8d9e2
https://hg.mozilla.org/mozilla-central/rev/fbd4e75a3d1b
https://hg.mozilla.org/mozilla-central/rev/6bee529b3fb0
https://hg.mozilla.org/mozilla-central/rev/4006b5658fdf
https://hg.mozilla.org/mozilla-central/rev/e6c585a81acf
https://hg.mozilla.org/mozilla-central/rev/0ebf590f9384
https://hg.mozilla.org/mozilla-central/rev/58221fa751ac
Assignee | ||
Updated•6 years ago
|
Updated•5 years ago
|
Description
•