Performance/FHR: Difference between revisions

m
no edit summary
(Added "Polling for startup timestamps" paragraph)
mNo edit summary
Line 9: Line 9:
4. ''' FHR event polling ''' Currently, FHR wakes up every minute to check if it needs to submit a report, expire any data, etc. This can be made neater by simply scheduling wake-ups for a specific time in the future.
4. ''' FHR event polling ''' Currently, FHR wakes up every minute to check if it needs to submit a report, expire any data, etc. This can be made neater by simply scheduling wake-ups for a specific time in the future.


5. ''' Polling for startup timestamps ''' If one of the startup milestones (e.g. session-restore) hasn't completed by the time FHR is initialized on startup, FHR polls every 5 seconds for up to 5 minutes to try to obtain this timestamp. Couldn't this timestamp be obtained at the end of the session or by registering a listener for the last startup event of interest?
5. ''' Polling for startup timestamps ''' If one of the startup milestone (e.g. session-restore) hasn't completed by the time FHR is initialized on startup, FHR polls every 5 seconds for up to 5 minutes to try to obtain the missing timestamp. Couldn't this timestamp be obtained at the end of the session or by registering a listener for the last startup event of interest?


6. ''' Chrome workers ''' Any disk or network operations should be moved entirely to a chrome worker to avoid unintentionally slowing down the main thread. For example, serializing 6-months worth of FHR data on the main thread before passing the string to Necko's thread-pool could cause jank (we've seen this problem with session restore). FHR can then use XHR from a worker to do uploads instead of re-implementing the functionality on the main thread & using XPCOM to open network channels.
6. ''' Chrome workers ''' Any disk or network operations should be moved entirely to a chrome worker to avoid unintentionally slowing down the main thread. For example, serializing 6-months worth of FHR data on the main thread before passing the string to Necko's thread-pool could cause jank (we've seen this problem with session restore). FHR can then use XHR from a worker to do uploads instead of re-implementing the functionality on the main thread & using XPCOM to open network channels.
Confirmed users
356

edits