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

On 7/19/2011 11:46 AM, Mike Shaver wrote:
>> 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,
>
> IMO, that's not really OK long term (e10s-term) -- the tabs will need
> to report their state back to chrome, so that the blocking goes the
> other way.

Right - I didn't know the E10s architecture yet (on my list...) ;-)

>> Others?  Any ideas out there?
>
> File-per-tab containing all the data for that tab, maybe?  Or two
> files per tab, to avoid re-writing the big sessionstorage data every
> time, if it doesn't change that often.  This would let us write out
> the current tab more frequently than background tabs, as well.

[ Hi Mike. Long time no chat  :-) ]

That can be done with many of these ideas, especially the DB-based ones. 
  And file-per-tab is pretty much the same as a DB, it's just 
filesystem-as-dumb-DB.  :-)  Not that it's necessarily bad.

Kyle (in .platform - that will teach me to cross-post) and Taras 
suggested LevelDB over SQLite (we don't really need much in the way of 
complexity here, mostly just safety against crashes and large blob 
storage - which may speak to files, since filesystems are good at that).

An intern has expressed interest in trying some of the options proposed.
I dropped some dumb testcode in the bug to help.

-- 
Randell Jesup, Mozilla Corporation
Remove ".news" for personal email