Open
Bug 930517
Opened 11 years ago
Updated 2 years ago
Add a scriptable way to know how much time was spent outside of the event loop
Categories
(Toolkit :: Async Tooling, enhancement)
Toolkit
Async Tooling
Tracking
()
NEW
People
(Reporter: florian, Unassigned)
References
(Blocks 1 open bug)
Details
When writing JS code that performs long operations that have to be on the main thread (eg. DOM modifications), it's usually possible to make the work happen in chunks, but there's no way to know how much time was spent since the last time events were processed.
I've heard that JS code shouldn't block the main thread's event loop for more than 15ms. It's possible to ensure that a function doesn't execute for more than 15ms by checking Date.now at the beginning and comparing it with the value of Date.now whenever the function is about to start more work that could be postponed to another iteration. However checking Date.now won't let the function know if it is executed after other code that has already spent a significant amount of time.
I think the platform should provide a scriptable way to know how much time has elapsed since the last time the event loop was processed.
Providing this information from the platform may also have benefits for the Gecko Profiler. If I understood correctly, it currently gets this information by constantly putting some JS code in the event queue, and comparing the timestamp of an execution with a timestamp of the previous execution; causing some CPU overhead.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•