This forum is for technical discussions that help to improve the performance of the Mozilla code

Randell Jesup | 19 Jul 2011 23:29

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

(Continue reading)

headers

Joshua Cranmer | 20 Jul 2011 00:35

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

On 7/19/2011 2:29 PM, Randell Jesup wrote:
> 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).
LevelDB is designed to sensibly handle values from the small sizes to 
multi-GB per value, or so I am told.

headers

Taras Glek | 17 Aug 2011 19:59

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

On 07/19/2011 02:29 PM, Randell Jesup wrote:
> 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.

So just to clarify. Conceptually it may be the same as a db. In practice 
keeping independent items in a file is a very bad idea. Ie if you have 7

(Continue reading)