Roc told me at the last all-hands that it shouldn't be too hard to discard layout data for a tab. Just set its browser element to invisible, iirc? Layout uses ~10% of my RSS, so if we could decrease this significantly, that'd be awesome, even if it only applied to pages without any plugins. I don't know how long it would take to recompute a page's layout. On mobile, I imagine we could tolerate this delay, since switching tabs is infrequent. On desktop, we could play tricks like recomputing a tab's layout data when you hover over it, and/or not discarding the layout data immediately.

> Just set its browser element to invisible, iirc? display:none. We need to fix bug 90268 and maybe scroll state restoration first, right? > I don't know how long it would take to recompute a page's layout. That depends on the page. You can test this on pages of your choice with this bookmarklet: javascript: var e = document.documentElement; var s = e.style; s.display = "none"; e.offsetWidth; var d = new Date; s.display = ""; e.offsetWidth; alert(new Date - d); On my mbp, for this bug report, the number is 7ms. For something like the HTML5 single-page spec we're talking 4 seconds on my machine. For the cnn.com homepage, about 150ms.

> For something like the HTML5 single-page spec we're talking 4 seconds on my machine. In bug 678392, they're talking about saving a screenshots of each tab (actually, of each shentry in each tab). Perhaps we could use something like that to make this lag suck less. OTOH, maybe it's better to think about session-restoring tabs which you haven't touched for a long time. We could session-restore tabs much less aggressively and still get more benefit than we would from this...

(In reply to Boris Zbarsky (:bz) from comment #1) > > Just set its browser element to invisible, iirc? > > display:none. > > We need to fix bug 90268 and maybe scroll state restoration first, right? Scroll state restoration should be OK. Selection state needs to be fixed too. Bug 619273 is ready to land but there may be other selection-related issues. There might be other lurking issues. We should do something here that's controlled by a pref. > On my mbp, for this bug report, the number is 7ms. For something like the > HTML5 single-page spec we're talking 4 seconds on my machine. For the > cnn.com homepage, about 150ms. It's a quandry. The large pages are the ones that would give the most RAM benefit.

One option I considered is interruptible frame construction... The problem is that the frame construction setup is, to some extent, breadth-first. That makes it a little more complicated to deal with than a depth-first setup like reflow.

Interruptible frame construction (and reflow) won't work too well if you're scrolled far down the document.

Yeah, indeed. For what it's worth, I just retested html5, and the style computation + reflow is closer to 9s now. :(

This could be a big win but we don't have a clear path forward nor somebody to work on it, so we'll make this a MemShrink:P2.