Gathering pause data should be low priority
Categories
(Core Graveyard :: Web Replay, enhancement)
Tracking
(firefox72 fixed)
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: bhackett1024, Assigned: bhackett1024)
References
Details
Attachments
(1 file)
After bug 1594042 there is still a lingering logpoint performance problem on large recordings. After the logpoint has been evaluated at all hits within a given segment of the recording (that associated with a saved checkpoint, which are spaced about 2 seconds apart), the pause data for those hits will be gathered. If there are other logpoint hits in the recording which have not been evaluated, they will be at the same priority level as the pause data and might take a while to handled by a child process. It would be better if gathering pause data had a lower priority than evaluating logpoints, so that all logpoint hits will be evaluated (or given to a child process to evaluate) before any pause data can be collected.
Benchmarking a test where I load up firebugs.dev, add and remove filters five times, then add a logpoint on the setFilter function, fixing this improves the time taken to evaluate the resulting logpoint hits from 45 seconds to 20 seconds. There is a lot of JS that runs on this page, and further improvements will be difficult I think without cloud integration.
|
Assignee | |
Comment 1•5 years ago
|
||
Pushed by bhackett@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3dbd6c286f4c Gathering pause data should be low priority, r=jlast.
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
Description
•