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

NEW
Unassigned

Status

()

4 years ago
4 years ago

People

(Reporter: Yoric, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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.
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.
> 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?
You need to log in before you can comment on or make changes to this bug.