Performance/FHR: Difference between revisions

Performance/FHR (view source)

Revision as of 20:37, 14 February 2013

369 bytes added , 14 February 2013

Added "Polling for startup timestamps" paragraph

Vladan

Confirmed users

356

edits

@@ Line 9: / Line 9: @@
 . ''' 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.
-. ''' 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.
+. ''' 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?
-. ''' Spinning of event loop at shutdown ''' We shouldn't be spinning the event loop at shutdown. It seems event-loop spinning was added to allow an FHR upload to finish before Firefox shuts down, but we could achieve the same effect by cancelling the upload and updating state atomically at the end of the upload.
+. ''' 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.
-. ''' Telemetry probes ''' FHR should track its first-run initialization time in Telemetry separately from subsequent initialization times. We should also change the existing Telemetry probes to accurately track the amount of time spent on FHR operations instead of tracking the wall clock time elapsed from issuing an asynchronus FHR operation to the operation's completion handler running. It's causing the probes to over-estimate the amount of time required by FHR operations.
+. ''' Spinning of event loop at shutdown ''' We shouldn't be spinning the event loop at shutdown. It seems event-loop spinning was added to allow an FHR upload to finish before Firefox shuts down, but we could achieve the same effect by cancelling the upload and updating state atomically at the end of the upload.
-. ''' Other comments ''' The current uses of Task.jsm are hard to read, they should be rewritten with better naming conventions or task closures.
+. ''' Telemetry probes ''' FHR should track its first-run initialization time in Telemetry separately from subsequent initialization times. We should also change the existing Telemetry probes to accurately track the amount of time spent on FHR operations instead of tracking the wall clock time elapsed from issuing an asynchronus FHR operation to the operation's completion handler running. It's causing the probes to over-estimate the amount of time required by FHR operations.
+. ''' Other comments ''' The current uses of Task.jsm are hard to read, they should be rewritten with better naming conventions or task closures.