Closed Bug 38621 Opened 20 years ago Closed 18 years ago

Defer loading of history related dlls till after the browser window shows up


(Core :: DOM: Navigation, defect, P4)






(Reporter: nisheeth_mozilla, Assigned: jag+mozilla)



(Keywords: perf, Whiteboard: [nav+perf])


(4 files)

shistory.dll gets loaded through xpconnect calls made from script that executes 
when navigator.xul's onload event handler fires.  Can we move the script that 
causes this dll to get loaded to another place so that this dll doesn't get 
loaded before the browser window comes up?
Will look in to it. Session history is created when  BrowserAppCore's window  is 
created and initialised. I'm not sure if we can do it after it comes up, 'coz we 
want to add the start page to session History too. What seems to be the problem 
Target Milestone: --- → M17
We want to load as few dlls as possible during startup before the browser window 
shows up.  Right now, dll loading accounts for more than 50% of the time to 
start up mozilla.
Move to M20 target milestone.
Target Milestone: M17 → M21
waterson: is there a meta bug this should be linked to? 
thanks, Vishy
Keywords: nsbeta1
Priority: P3 → P4
nav triage team:

Marking nsbeta1+
Whiteboard: nsbeta1+
Not confident that this can make it to mozilla 0.9 (which I believe is the date
for nsbeta1). 
Target Milestone: --- → mozilla1.0
cc'ing people in Nav team ....

Looking at the way, browser starts up, SH is initialised in 
BrowserAppCore::ReinitializeContentWindow() which gets called from 
navigator.js's Startup(). The start-up page is also loaded from here by directly 
accessing the docshell for the content area, see navigator.js's loaduri(). we 
need SH in place before the start page is loaded so that the startup page can be 
added to SH too. If we could load the start page after the browser window chrome 
is displayed, and route the startpage load thro' BrowserAppcore OR whatever 
replaces it, instead of calling directly to the docshell, we can delay the load 
of SH too.  I think  by doing small rearrangement of code in navigator.js, this 
can be easily achieved. One of the goals of the  Nav team was to get rid of OR 
replace BrowserAppcore.  Is it still the case? According to waterson's email 
yesterday SHistory.dll takes about  50 msec to load. It would be nice to 
save that time during startup.
well, we want to get rid of as much of the appcore as possible.. the irony is
that mSessionHistory is never actually used in nsBrowserInstance! 

cc'ing jag to see if he knows more... I have a feeling we can just whack this.
I've got a patch lying around for that change somewhere, let me dig a little :-)

alecf, mSessionHistory actually is used. At startup, it's nsnull, so a new
session history object is created, stored in mSessionHistory, and set on the
docShell... Then when a theme switch occurs it is read from mSessionHistory and
set on the newly created docShell. The funny thing is though that this is also
happening from nsFrameFrame, if I recall correctly, so this code here can
probably go away (even though the code in nsFrameFrame is, necessarily, evil).

Anyway, let me see what I can come up with as far as setting it the first time
from Startup goes.
I agree with jag.  During a theme switch, SH used to get re-instated to the new
docshell in nsBrowserInstance::ReinitializeContentWindow(). But this function is
not called anymore.So, Back, forward does not work well after a theme switch.
I have a bug on that. For this bug however, I would like BrowserInstance to hold
on to mSessionHistory.
I've got one too (bug 68662). I know what's caused it (me!) and I've got a
possible solution (back me out) and another one (listen to stylesheet changes
and re-init from JS). I currently have a hack which puts back proper support in
BrowserInstance and adds support to navigator.js where needed, but it's ugly.

Anyway, the session history should be stored and set from
(yet another ugly hack), so I think they can be removed from BrowserInstance.
Except of course that someone needs to set it the very first time.

Okay, let me stop talking and come up with a patch.

However, what happens when session history isn't set? How would this influence
the page cycler?

It looks to me like we could set the session history right before,
which still means we can move it down from
and delay loading it slightly.
jag: Your patch is 1) moving the code in ReinitializeContentWindow() to JS and 
the 2) evil hack in nsFrameFrame.cpp seems to put it back after a theme switch. 
However 1) still happens before the window shows up at startup, thereby 
contributing to startup time. I want to initialize SH after the browser window 
shows up and load startpage after that. Is there some kind of listener or 
broadcaster that navigator.js can hook up to, so that we know when the window is 
up and showing and we can initialise SH then.
Yeah, alecf and I discussed this and we came up with the following:

1) make GetSessionHistory in nsDocShell lazily instantiate session history
(instead of us having to explicitely set it)
2) replace |if (startPage) loadURI(startPage);| with |if (startPage)
setTimeout(loadURI, 0, startPage);|. That moves the actual loadURI out of onload
so the window will continue and display.
Please don't make docshell generically create Session history. This makes anyone 
who creates a docshell automagically get a history object. We do not want that. 
For embedding purposes, we want to keep the boundaries separate. Neither do we 
want a nsFrameFrame.cpp type hack in docshell.

Instead, extending your idea on SetTimeOut(....), something like the following 
can be done...

startup() {
// Existing code, with out any SH creation
setTimeOut(LoadStartpage, 0, startpage);

LoadStartPage(startpage) {

1) Check if the browser has a SH object
2) If not create it
3) Call Loaduri(startpage);

I'm still not sure if this will happen after the browser shows up. Can someone 
comment on that. 
Well, I've tested the setTimeout yesterday and it looked to me like the window
first shows, before starting the page load, as opposed to without the patch
where the window would show up while loading the page. In some very unscientific
stop-watch timings done on this 233MHz 64MB RAM the total time till the page
finishes loading remains the same, but the window appears one or two seconds.

radha: why would step 1 be necessary? That code should only be called from the
timer started in Startup().

alecf: so instead of doing true lazy instantiation, I like radha's suggestion
above. Just always create and set it from the LoadStartPage.

radha, alecf: so we'll end up with something line:

function Startup()
  // other stuff
  setTimeout(finishInit, 0, startPage);

function finishInit(aStartPage) // LoadStartPage?
  1) create session history object and set it on the docshell
  2) if (aStartPage) loadURI(startPage);
Ah, I see one possible reason for step #1 (nsBrowserInstance currently also
creating and setting the session history object). It shouldn't be needed any
longer when bug 68662 lands (part of which is necesasry to not create the
session history object early).
jag: yes, if this timer is going to go off only during startup and after 68662 
lands, step 1) is not required and what you have suggested should work. Should I 
make these changes after 68662 lands OR you want me to make it?
I could incorporate this into the patch for 68662 and land them together.
this also suggests that we can *probably* delay the initialisation of urlbar
history and global history until after the window is displayed.
urlbarhistory.dll is primarily used for autocompletion. Adding to the RDF
resource  happens directly in sessionHistoryUI.js without interfering with the
dll. Right now it gets initialised by the autocomplete widget, when the urlbar
is created. However the service is not actually used until someone tries to
autocomplete a url.  May be we can delay the initialisation of this service
until then. Have to check with ducarroz.

For global history, we use it before startup to figure the last visited page, if
the home page is set to lastpage visited. But this can be done thro' Prefs.
There is already a pref, "browser.history.last_page_visited" which looks like a
unused pref.
New bugs? :-)

Though, I'm sure urlbarhistory can be lazily instantiated and set from the
autocomplete xbl. Btw, is that dll still needed, or could that be moved into JS
(or is JS deemed too slow?)?

As to global history and recalling the last visited page, I guess a pref could
be used for that, but then the pref should be set (and the prefs flushed??)
whenever a page finishes loading. One common pattern is to use that setting so
after you crash you can continue right where you left.
I have a way to defer the reading of the global history into memory until the
data is actually needed... my patch still needs testing, but I'll attach here in
a bit.
I had to special-case about:blank because if you start without a homepage, we
load about:blank just so we have something to paint in the content area...

Anyway, this allows me to start the browser without a homepage, go use mailnews,
and the history DB never gets opened, until you visit your first page. If your
history is very large, then this speeds up the appearance of the first window
pretty signifigantly.

I did more testing, it's looking pretty good.
looking for r= from anyone and sr= from waterson? :)
So, if I have a home page, does it still allow a deferred load? What about the
link color change on the home page?
yes, everything will work exactly as before - but the reading of history.dat
will be delayed until after the window appears. if you have no home page,
history.dat will STILL not be loaded until you visit your first page.

This also means that if you start mozilla -mail, that history.dat will not be
read in..
> yes, everything will work exactly as before - but the reading of history.dat
> will be delayed until after the window appears.


> if you have no home page,
> history.dat will STILL not be loaded until you visit your first page.

Hmmm... This would only work if all loadURIs would create a sessionHistory and
set it on webNavigation if it doesn't exist yet. Within the browser we can
fairly easily guarantee this by putting it in navigator.js' loadURI, but things
like x-remote would be in for a surprise.

I think it would be far easier to just always create and set the sessionHistory
object on webNavigation right after the window shows, like I already suggested a
bit up.

Changing the summary to reflect the bug morphing :-)
Summary: Defer loading of shistory.dll till after the browser window shows up → Defer loading of history related dlls till after the browser window shows up
jag: What ever you suggested for SH still stays. history.dat has nothign to do 
with SH. It is only used by Global History.
Alec, jag, can I give this bug to one of you, since I don't have any patch for
this bug?
Sure, I'll take this.
Assignee: radha → disttsc
Keywords: perf
r=shaver, with the addition of the requested comment explaining the subtlety of
the sessionHistory assignment's execution order WRT the progress-listener
jag you kick ass! off to try this now
this is so great.
Attached patch updated patchSplinter Review
that is an updated Global History patch against the latest tree, with some
additional error checking and warnings fixes
r=waterson if you still need it.
The patch that was checked in breaks profile switching. Before, I could call
CloseDB() when a profile was going away and OpenDB() when the new profile
started up and all was well. With this change, a call to CloseDB followed by a
call to OpenDB() does not work as expected - instead it causes a crash.
If this is going to be happen, CloseDB() needs to set that var to nsnull. 
ugh, you're right. I'll fix that to set mTable to null.
Mass move to
Assignee: jag → jaggernaut
Actually, I'll just hand this to alecf.
Assignee: jaggernaut → alecf
nav triage team:

moving nsbeta1+ from status whiteboard to keywords
Keywords: nsbeta1nsbeta1+
Whiteboard: nsbeta1+
Whiteboard: [nav+perf]
nav triage team:

Need to look into this for startup performance. Marking mozilla0.9.4 and
reassigning to pchen
Assignee: alecf → pchen
Target Milestone: mozilla1.0 → mozilla0.9.4
nav triage team:

Paul hasn't had time to look at this. Reassigning back to alecf and moving to
Assignee: pchen → alecf
Target Milestone: mozilla0.9.4 → mozilla1.0.1
Blocks: 7251
Blocks: 71781
No longer blocks: 7251
can we fix delay reading/loading history DB in the next couple milestones (0.9.6
or 7?)
Taking over bug.
Assignee: alecf → dp
Target Milestone: mozilla1.0.1 → mozilla0.9.7
mork.dll : Get loaded after window is visible. Dimished the value of delaying it
anymore. Getting history.dat loading faster is being tracked elsewhere. So this
aint an issue for startup.

shistory.dll: get loaded even before main window visible. That needs to be
delayed. I think about:blank is causing it to be loaded. Need to check.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
I suspect shistory.dll is getting loaded because we create a session history
instance and set that on the browser from the browser's constructor (see
browser.xml). This is necessary to pick up the page (which generally isn't
about:blank) that gets loaded from navigator.js's startup function.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Deprioritizing startup perf and focusing on footprint. Moving past 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Reassigning to a real person.
Assignee: dp → radha
I think jag did some work on this last year OR this is already done. The changes
have to happen in the navigator in the order in which components  are created. 
Assignee: radha → jaggernaut
We can't make any changes to navigator without sacrificing functionality.

I don't think there is anything else we can do here.
Closed: 18 years ago
Resolution: --- → WORKSFORME
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.