1096072 - [Session Restore] Does Session Restore cause too many reads from places.sqlite?

Status: NEW

(Firefox :: Session Restore, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

We have unchecked reports (http://www.ghacks.net/2014/06/27/mozilla-launches-improved-session-restore-firefox-33/#comment-2250412) that collecting session data causes many accesses to places.sqlite.

This makes sense, as http://dxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/SessionHistory.jsm#66-140 requires hitting into history.

We should investigate whether:
- this is the case (I believe so);
- this has a performance impact, in terms of either jank, battery or disk thrashing;
- this can be improved.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

Any idea what exactly accesses Places here? I can't see anything obvious. SessionStore *should* not cause places.sqlite reads at all. We should take a closer look at this although the anecdotal comment doesn't seem like a strong indicator to me that this is actually happening.

Comment 2

[WADA:World Anti-bad-Duping Agency]

> Bug summary : Does Session Restore cause too many reads from places.sqlite

Answer is : "many reads from places.sqlite" can occur by Session Restore, because "Session Restore" is "access to many sites at same time upon restart".

URI of Tabs is stored in sessions.json, and Tabs are opened upon restart and the URIs are loaded at same time.
  { ... , "tabs": [ { "uri" : "http://forums.mozillazine.jp/..." , ... , ... } , { "uri" : ... } , { "uri" : ... } ] , ... }
It's similar to "Open All in Tabs" on folder of Bookmark which contains many bookmarks.
So, many accesses to places.sqlite usuaally occurs.

IIRC, feature like following is already available :
   Don't do session restore immediately upon restart. Do it later, when user requests it.
Right?