Simon Fraser wrote:
[EMAIL PROTECTED]">How would it be optional? A pref? #define/build time?In article [EMAIL PROTECTED]"><[EMAIL PROTECTED]>, Doug Turner
<[EMAIL PROTECTED]> wrote:Radha Kulkarni wrote:Doug Turner wrote:it sounds like (based on no real data) that the
nsILayoutHistoryState reference holds onto alot of stuff in terms
of memory footprint. Do you have any feeling as to exactly what
it costs to mantain form values and scrollbar positions?Bug http://bugzilla.mozilla.org/show_bug.cgi?id=62651 is about
reducing the size of nsIlayoutHistoryState owned by Pollmann. There
are some #s on how much this structure is using and how it can be
reduced.Thanks for the bug number. We should make saving the
nsILayoutHistoryState in session history optional. In the short
term, this should be a big win for devices/appli! cations that do not
care about saving form data or scrollbar position.
[EMAIL PROTECTED]">We're starting to get into some Least Recently Used methodology here, when, IMO, we should fix the underlying problem first (layout history state size (apparent culprit)).I vote for the layered approach, where we only save form and scroll
state for the last N URLs (N perhaps dependent on memory pressure),
so go back and purge old history entries of non-essential data.
1. We need a max cap on entries no matter what (Radha's whacking this in now using a pref (radha, if there are other sh prefs that can be categorized together, can you create a pref file specific to sh prefs? see http://bugzilla.mozilla.org/show_bug.cgi?id=62755).
2. How does session history differ from global?
3. A simple LRU comparison can be applied each time an entry is made in the list (do entries already have a date field?). It would be driven by a history pref ("don't keep shist longer than X hours" or whatever).
4. Memory pressure: When shist get's mem_pressure notification, it would first cleanup based on the LRU algo, if that wasn't enough (determined by shist itself), say it didn't clear more than 75% of it's state, it could start ripping things out from there. Last time I checked, mem_pressure callbacks were just "clean up your act" (single level not providing any numbers or data or anything), I don't see how you could be selective enough in a callback to handle your proposal Simon.
I don't see why we'd want to special case scroll and form data entries only (outside of maybe providing the ability to disable that kind of history completely (note: I can't see any practical need for this right now (unless of course saving those things is soooo expensive, *and* we can't fix the size problem easily), everyone basically needs/wants that kind of capability). Clearing history, from a users perspective, is always _time_ based, not "have I filled out a form" based.
Jud
[EMAIL PROTECTED]">
