Confirmed users
381
edits
Performance/FHR: Difference between revisions
no edit summary
(Initial write-up of etherpad comments) |
No edit summary |
||
| Line 1: | Line 1: | ||
1. ''' JSON vs SQLite storage ''' The SQLite schema used in FHR is overly complex and seems over-engineered. We could simplify FHR storage by storing data in JSON files. | 1. ''' JSON vs SQLite storage ''' The SQLite schema used in FHR is overly complex and seems over-engineered and has a degree of redundancy. | ||
We could simplify FHR storage by storing data in JSON files, this will cut down amount of IO and fsyncs. | |||
We should flush out current session data on shutdown(without fsync to delay shutdown). | |||
2. ''' Flushing prefs ''' FHR currently uses browser prefs to store data such as lastPingTime, lastSubmitID, last submission success, etc. It will need to explicitly flush the prefs store to disk for this information to survive a crash. Currently, prefs can only be flushed on the main thread, and this is likely to be a source of jank as typical pref files are sizeable. | 2. ''' Flushing prefs ''' FHR currently uses browser prefs to store data such as lastPingTime, lastSubmitID, last submission success, etc. It will need to explicitly flush the prefs store to disk for this information to survive a crash. Currently, prefs can only be flushed on the main thread, and this is likely to be a source of jank as typical pref files are sizeable. | ||