113721 - Major speedup of Back (and Forward) possible

Status: VERIFIED DUPLICATE of bug 38486

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[Randell Jesup [:jesup] (needinfo me)]

I've had a very good idea how to speed up back and forward, at the cost of
memory and some code.

Use a pseudo-tab to store the previous page.  I.e., when you click on a link and
a new document replaces the old, instead of tearing down the old document save
it into a hidden 'tab' structure.  (We'll need to fire off things that normally
occur at destroy time, like onUnload.)  If the user then goes Back, instead of
reloading the page (probably from cache), just swap it for the current document
(and move the current document into the history pseudo-tab, and run
onLoads/onUnloads, etc).

This will make N (where N is the number of documents cached) Forwards/Backs very
very fast.  Even if N is 1, this will be a VERY large boost in usability and
perceived speed.  Note that we may need some heuristics/prefs for number to
cache (if we want to contemplate more than 1), and perhaps a limit on the
size/complexity of pages to cache (to limit the bloat).

Much web browsing is "click....scroll down/up...back....click...etc".

This doesn't have to actually be in any way tied to tabs, but a lot of the
infrastructure to do this exists in the tab code, so we'd either want to use it,
or clone and modify it.

We'd probably want a unified cache, not a cache per tab or window (though
perhaps I'm wrong.
  
The logic in back/forward shouldn't be too complex other than deciding if it
should be cachable, which may be the same logic for caching HTML (plus perhaps
size/complexity limits).

After I flesh this out some we should add a bunch of people to this discussion.

Comment 1

[Oliver Klee]

Related to bug 33269.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

In a previous browser I worked on (spyglass variant; IE2.0 was based on
spyglass), we used a cache size of 4 (if I remember correctly).

The idea isn't a new one, really, other than the part about leveraging all the
code written for tabs (and since tabs show how fast we can swap documents in a
window).  This has been discussed ad nauseum in some other bugs (see above) and
in n.p.m.performance.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do you really want an actual quasi-tab, or do you just want to keep the docshell
alive?

What do you intend to do about scripts that are running in the documents that
are being cached?

Comment 4

[Ashley Bischoff (blog at handcoding.com)]

David: As I understand it, the reporter is "just" proposing to keep the docshell
alive (à la bug 84286), but that he's suggesting that some of the Tabbed Browser
code may be able to be reused to that end (such as using hidden tabs for storing
previously-visited pages).

My personal preference is for docshell persistence -- irrespective of how that
is achieved ;).

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

I want to keep the docshell alive; if we can reuse some of the tab code all the
better.  The tab code (and how fast it switches) just renewed the idea (from the
.performance discussion many months ago) about caching the document model.

We'd need to stop any scripts, and cause all unloads to fire like you would
normally if you went to another page.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

> We'd need to stop any scripts, and cause all unloads to fire like you would
> normally if you went to another page.

This implies that you'd also need a way to start them up again when returning to
the cached page.  That may be difficult.  I'm not sure.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

We'd need to run anything we normally (or reasonably) run on Back.  Looking at
Spyglass code, it _appears_ that if we still have the document (docshell), all
we may need to do is fire OnLoad's.  Of course, that was a simpler browser.

Comment 8

[Johnny Stenback (:jst)]

This thought has been around for ever, and it's already reported as bug 38486.
Duping.

*** This bug has been marked as a duplicate of 38486 ***

Comment 9

[Sebastian Späth]

verifying dupe