Improve stepping performance
Categories
(Core Graveyard :: Web Replay, enhancement, P1)
Tracking
(firefox71 fixed)
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: jlast, Assigned: bhackett1024)
References
Details
Attachments
(1 file)
When Harald and I recently tested slack.com, scanning to a message and playing to breakpoints was really fast, but stepping back and forward was relatively slow.
It would be nice to take advantage of the caching architecture and be able to step fairly quickly as well.
| Reporter | ||
Updated•6 years ago
|
| Assignee | ||
Comment 1•6 years ago
|
||
| Assignee | ||
Comment 2•6 years ago
|
||
This patch goes on top of bug 1579749 and allows snapshots to be taken at the entry point of the frame for which we are filling in the pause data at its steps. I benchmarked this on todomvc --- add a bunch of todos, rewind to the middle of the last render() call on an item, then calculate how much time it took from the rewind to when we have pause data for all nearby steps. Without the frame entry snapshots, this took 10.5 seconds, and with the frame entry snapshots this took 5.5 seconds, about a 2x improvement. There are still some more steps (!) to take here:
- We should prioritize the steps that are closest to where we are currently paused.
- We should only be getting pause data for the points where the user will land if they press on stepping buttons or otherwise interact with the UI. Right now we get pause data for all points in the frame where a breakpoint is hit, which is wasting work on breakpoint hits that are not places where steps will actually land.
I'll do some more benchmarking later and look into fixing these.
Comment 4•6 years ago
|
||
| bugherder | ||
Updated•6 years ago
|
Updated•5 years ago
|
Description
•