Open Bug 1486669 Opened Last year Updated 9 months ago
[meta] Web Replay: Recording performance
This bug is a tracker for performance issues when recording websites. Recording a website incurs overhead, but that overhead should not be noticeable on a powerful computers, or on slower computers with rewinding disabled (in which case we only spawn a recording process, and no replaying processes). This applies to both simple and large/complex websites. Currently, a lot of websites feel really good when recording, though I've never done any measurements. Some use cases feel really slow or laggy. Investigating and fixing these is crucially important.
Change the public record/replay API so that callers specify the address of the atomic value (or a nearby address, as long as the same address is always used for the same atomic) being recorded.
Assignee: nobody → bhackett1024
Attachment #9020208 - Flags: review?(nfroyd)
Fix users of the atomic access API outside of toolkit/recordreplay.
Fix users of the atomic access API within toolkit/recordreplay.
Core logic to use a pool of locks for atomic accesses, and avoid using system mutexes when recording them.
Comment on attachment 9020208 [details] [diff] [review] Part 1 - Specify the address of atomic values when recording ordered atomic accesses. Oops, I attached all of these to the wrong bug, sorry about that.
10 months ago
You need to log in before you can comment on or make changes to this bug.