Firefox/session restore
What is Session Restore, why this page?
Session Restore is the service that saves the state of Firefox while the user is browsing so as to be able to restore it after a shutdown or a crash.
This service is extremely useful but is also quite expensive. It was designed a long time ago, when users only had a few tabs, when DOM Storage didn't exist and before people started uploading Gigabytes of data. For this reason, it is undergoing major refactorings and redesigns.
This page is about documenting things progressively.
Collecting and saving data
TBD
Data we collect
- Open windows and tabs - Closed windows and tabs (closed tabs, tabs in closed windows, closed tabs in closed windows) - Loaded pages before and after (back and forward buttons) - Form data (for the case of a browser or system crash) - ... (TBD)
Data we do *not* collect
TBD
Privacy
TBD
Restoring sessions
TBD
Redesigning sessionstore.js
Our problems
During startup
We need to read + parse everything, even when we restore-on-demand or do not restore at all:
- Slower startup
- Much I/O
- CPU-hungry
- Memory-hungry
During runtime
We need to serialize + write everything, even when only a single tab has changed.
- Slower runtime
- Much I/O
- CPU-hungry
- Memory-hungry
During shutdown
- During shutdown, final serialize + write everything
- Much I/O (annoying)
- Slower shutdown (less annoying)
- CPU-hungry (less annoying)
- Memory-hungry (less annoying)
Improvements
Reduce amount of data stored
Good for: everything.
Limitations: there is only so much data we can cull away.
Difficulty: 2/5.
Compress data
Good for:
- startup I/O;
- runtime I/O;
- shutdown I/O.
Bad for:
- CPU (not much);
- Memory (not much);
- Human readability (a lot).
Difficulty: 1/5.
Journalize files, consolidate them on idle-daily and shutdown
Good for reducing serialize + write:
- runtime I/O;
- runtime CPU use;
- runtime memory use.
Bad for:
- shutdown CPU use (probably not a big deal);
- shutdown memory use;
- runtime I/O, CPU, memory in case of crash;
- addon-compat;
- getBrowserState() & co. use a different path from SessionSaver.run.
The consolidated version would not hurt readability.
Difficulty: 3/5.
Save separately index (one file), tabs (one file per tab)
Good for:
- startup I/O (unless the user);
- startup CPU;
- startup memory;
- startup duration;
- runtime I/O;
- runtime CPU;
- runtime memory;
- runtime duration.
Bad for:
- garbage-collecting files may be difficult;
- addon-compat;
- getBrowserState() & co. use a different path from SessionSaver.run.
Readability would be ok.
Difficulty: 4/5.
Binary format that can be loaded/modified piecewise
Good for:
- startup I/O;
- startup CPU;
- startup memory;
- startup duration;
- runtime I/O;
- runtime CPU;
- runtime memory;
- runtime duration;
Bad for:
- debugging;
- extensibility;
- garbage-collecting will be difficult;
- getBrowserState() & co. use a different path from SessionSaver.run();
- readability.
Difficulty: 5/5.
Sqlite
Good for:
- startup I/O;
- startup CPU;
- startup memory;
- startup duration;
- runtime I/O;
- runtime CPU;
- runtime memory;
- runtime duration.
Bad for:
- backups;
- use of flush() is bad for battery & rest of the system;
- garbage-collection will be moderately difficult;
- getBrowserState() & co. use a different path from SessionSaver.run.
Difficulty: 3/5.
Other DBMS
?
Reducing the amount of data we store
History entries
TBD
DOM Session Storage
TBD
POST data
TBD
Forgetting closed tabs/windows after a time
TBD