Re: SessionStore size - Bloat in sessionstore.js from Google and others causing major UI freezes

On 7/19/2011 10:51 AM, Randell Jesup wrote:
> [ This seemed long for in-bug discussion...  (And it's a pain to edit 
> there.)  We can move it back there if people wish. ]
>
> As identified in bug 669034 (and bug 669603), we have a serious 
> problem with bloat in sessionstore.js caused largely by websites 
> storing large amounts of data in the dom sessionstorage.  See 
> http://dev.w3.org/html5/webstorage/#dom-sessionstorage for more info. 
> (My apologies for the naming confusion between "sessionstore.js" and 
> "sessionstorage".  Not my doing. :-)
>
> For example, in a fresh profile browsing to google.com and typing two 
> words causes a 366KB sessionstore.js file.  Having Google anywhere in 
> the history of a tab typically uses 200-700KB of data.  
> sessionstore.js files of 5, 10, 20 and even 50MB are not unheard of.
The reason we are storing "session" data in a file is because we want 
session restore to work, right? Otherwise we wouldn't need to save this 
data...
> e) Push the processing of the per-tab data over to a background
>    thread/process.
>
>    May play into work with Electrolysis.  Not necessarily at odds with
>    other options above.  Fetching data from each tab would be the
>    primary UI-blocker, and it would only block long enough to pass the
>    data for one tab to the sessionstore background process.  At the
>    cost of memory, could keep data for tabs around and fetch data only
>    from those that indicate dirty state.
There is no reason why session restore should have to block the UI ever 
in an electrolysis world. What should happen is that when a page 
navigates (or session data changes), the content process sends the 
change over via a message. Because we are targeting multiple content 
processes, this data will be received at various times by chrome.

The policy for content processes (enforced by the message-passing 
system) is that the chrome process must not (cannot) block on content.

Offhand, sqlite sounds like a good choid, because most of the other 
options seem to be basically be emulating a database/filesystem, and 
we've already got one available with builtin async IO and the other 
features you really want for this. I don't think that downgrade issues 
are particularly relevant, because we don't normally treat saved 
sessions as "precious" data.

It sounds like you ought to own bug 516755?

--BDS