Confirmed users
356
edits
(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 | 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. | ||