Closed Bug 36283 Opened 24 years ago Closed 23 years ago

Stay resident in order to load faster

Categories

(SeaMonkey :: UI Design, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jruderman, Assigned: cathleennscp)

References

Details

(Keywords: helpwanted, perf, Whiteboard: fixed in bug 75599 using a different strategy)

Attachments

(7 files)

One of IE's major advantages over mozilla is that it loads faster by loading 
once, when the operating system starts.  While you could complain "that just 
makes the operating system take longer to load", it actually is advantageous 
overall, because it only needs to be loaded once (provided it doesn't crash).

I'd like to see a new feature added to mozilla to make it stay resident, even 
when all browser windows are closed.  When the user tries to open a mozilla 
window, it would instead call the new-window code from the part that's already 
loaded, reducing the apparent loading time by perhaps a factor of five.  


The prefs would probably look something like:

[x] Keep mozilla resident after all mozilla windows are closed.
  [ ] In addition, load mozilla into memory when my operating system starts.


The system would have to be pretty robust:

(1) it should unload correctly if the browser crashes
(2) the user should be able to kill it by clicking on something and 
selecting "quit and unload" in case (1) doesn't happen.  for win32, a system 
tray icon would work.
(3) it would have to be able to handle multiple versions of mozilla, either by 
simply preventing them from intermingling or actively unloading unneeded 
versions in order to conserve RAM.
adding helpwanted keyword to see if anyone will pick this up and reassigning to 
nobody@mozilla.org where helpwanted bugs live
Assignee: asadotzler → nobody
Keywords: helpwanted
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
The Mac equivalent would be offering the option for the Mozilla base (XPCOM, 
XPToolkit, etc) as an Extension. If the extension wasn't found on Mozilla 
startup, then the shared libraries would be used as before.
might depend on bug 50424.
*** Bug 48846 has been marked as a duplicate of this bug. ***
*** Bug 54826 has been marked as a duplicate of this bug. ***
why not do something on the mac with shared libs like IE?
I believe this would be a great feature. There has to be a way to make it so 
that if the browser crashes, it doesn't take down this loader factory, and if 
the loader factor crashes, it reloads without closing the browser. The loader 
factory also has to be small enough that it won't bog down their system too 
much when they aren't using Mozilla. Also, if this loader program stayed open 
when Mozilla crashed, possibly it could reload the current session information 
that was stored when the user was using Mozilla (as in bug 63094), and restore 
everything back to exactly the way it was before the crash.
*** Bug 64141 has been marked as a duplicate of this bug. ***
OS: All → Windows 3.1
Summary: RFE: stay resident in order to "load" faster → Stay resident in order to load faster
[Fixing OS that mpt messed up...]
OS: Windows 3.1 → All
Is it possible that the factory could be a seperate process and somehow copy 
memory in a way that if Mozilla crashed it wouldn't affect the factory? For 
instance, could it already have the data structures initialized (ie class 
constructors) and somehow copy them to a new mozilla process without having to 
translate pointers, or reinitialize them, etc?
Keywords: nsbeta1
*** Bug 64814 has been marked as a duplicate of this bug. ***
*** Bug 66166 has been marked as a duplicate of this bug. ***
I had an idea like this a while back. I thought of perhpas replicating the mail
notification stub of 4.x to load commonly used libraries of Mozilla at (Windows)
startup. I'd be nice to have new mail notification back in the system tray plus
we could piggy back on this and load most the browser, with prefs controling how
much gets loaded of course. From last week's meeting, it seems that dynamic
profile switching is almost working and is quite fast which could also be
incorporated. 

If Mozilla or the stub crashed, perhpas do something like Windows Explorer does,
simply restart and make it look to the user like nothing big happened. With most
users loading many apps like IM and Virus Scan at startup, a little performance
hit on startup is a small price to pay for a huge win on individual browsing
instances. If IE "cheats" this way, why can't we?

What do you think?
w2k does a good job of swapping dll's out to disk when they're not in use, i 
expect that mozilla wouldn't get the performance benefit we expect.

Relaxing dependencies is probably the better gain.
w2k is not that common of a platforms, and besides it is faster to swap a dll's
code pages in than to load it in the first place, especially if the loader needs
to rebase it(!) - I agree that limiting deps is a good idea, but even when that
is done, preloading the DLLs will probably help load time a lot - MS does it for
their Office DLLs...
You can look at swapping out the DLL's as a good thing. I mean, look at it this 
way: How often do you use a browser? Mine, and I think more and more users, will 
have their browser open all day and do everything with it. The parts (and 
DLL's) they use should stay resident and the OS will automatically take care of 
swapping out those that aren't used frequently. This is much less expensive than 
loading and unload everytime you start the browser. Let's just all the nasty 
init and loading that the begining of startup while we're fethching our 
coffee. Just my 2 cents....
that's a good point, nearly all of our libraries collide [i think about 4 
don't].  I can attach a dependency walker output showing this. Is it worth 
filing an arch bug requesting that we set bases that generally don't collide?
I really don't know about most useres having the browser open all the time. What
about, for example, family computer that gets used to dial up to the net an hour
every few weeks?

Loading DLLs on system startup should be optional.
Mozilla loads a lot of junk it doesn't need on startup. IE: Why not load java 
until needed?
Anyway... Swapping occurs on most systems by just minimizing Mozilla and using 
another large program? (I think). By the way... Swapping is slow too in 
Windows. The two things that bother me are load up speed and task switching to 
Mozilla. Both are slow.
Marcus: You give people control over this and they will disable the startup not 
knowing better. You will have articles telling people how to do it. I think it 
should be something that can be changed in the registry only.

The factory should just be small enough that it preloads on startup those DLLs, 
etc that take the most time on startup.
*I'll* disable it, for myself (I use moz in roughly 50% of my sessions on my win32 box, and I don't want a program in memory that I don't use) and I'll definatly recomend that it gets disabled for people who use Moz once in a blue moon why waste their time starting up for somehtign that's going to get rearly used? Remember that It's not jsut people that surf every day will use Moz and it's decendents.

I know IE does it, but it's used for explorer so it's not totally wasted. Office does it, but you can remove Office Fast Start quite easily. If it's disabled through a the preference, the pref can describe pros/cons of enabling.
We can make it even "smarter" than that. Just like the automatic hiding menus in 
Windows 2000 and Office 2000, when Mozilla hasn't been used for a set time, it 
can unload itself. Or, on the flip side, as soon as we run out of virtual memory 
and need to start swapping, and we're not running, we can unload then. 
Oooh, I like that Idea. By unload - it could unload all of its DLLs but keep a 
small (maybe 10k) portion open to poll occasionally to see if there is enough 
mem again to reload all the DLLs. Good thinking, peter.

Basically, the stub would start on system startup. It would read from a data 
file how long Mozilla is used per windows session, and based on that decide to 
continue or abort. If it continued, it would load all the DLLs needed and wait. 
Every second or so it would poll how much system mem is left. If the mem is 
getting low, it would unload all the DLLs (If they really take up that much 
mem), and continue to poll as just the stub. If it detected a plethora of mem 
again, it would reload the DLLs. 

This could be a third option: meaning 3 options.


Prefs: ?
------------------------------------------------
Load on Startup Options. Note: Internet Explorer loads
itself on startup to make itself faster to start when called upon.
(Radio) Load Automatically on startup (FAST)
(Radio) Use smart load (FAST but unloads if you are low on mem and doesn't load 
if Mozilla isn't used often)
      (Text) ___ Amount of average time Mozilla should be run in order to load 
Mozilla on system startup
(Radio) Don't load Mozilla on startup
perf radar
Keywords: perf
Ok, here's a little test I came up with on Windows for the benefit of 
pre-loading. Try it and let me know your comments:

1) Download and install NS 6.01 (or at least an optimized build)
2) Add a URL as an argument to the Shortcut put on your desktop (notice this 
test doesn't work without an argument)
3) Launch NS 6....wait the usual dozen seconds....then minimize it.
4) Now click on the NS 6 icon again. Notice how amazingly fast the browser 
starts. Takes just more than a second on my machine.
5) Now lauch a bunch of other apps to force NS 6 to get swapped to disk.
6) Launch it again, and it's pretty fast!
Sorry for the spam, just adding to CC list
I don't believe this is at all desirable under Mac OS and don't advocate it's
application on that platform.
I've been asked to add this to the mozilla1.0 radar by someone who wants this a
lot more than me :). I'm in favour as long as it is an option, the big problem
with Windows is that too many applications take the liberty of installing
themselves to preload on start up without the users permission. Also if we do
implement this on Windows and use a system tray icon for this purpose then any
auto notification for mail (bug 18729) should also use this system tray icon as
many peoples system trays are already full of icons.

I can't see many people on Linux wanting this feature and it'd also be more
difficult to implement on Linux so it's probably gonna be a Windows (and Mac??
dunno what the majority of mac users feel about this)

But option is the most important word here :)
Keywords: mozilla1.0
Mozilla is so fast now (at least in Windows) that this is not really necessary. 
The effort that goes into this should instead go into making performance 
enhancements especially on window loading and startup. I recommend marking this 
WONTFIX.
Startup time for mozilla may be getting better but it still doesn't start up as
quick as IE does mainly because IE can load parts at startup (that includes the
toolkit too).

So I still think this is a valid request. It go well with something like 98lite
(http://www.98lite.net/) that strips IE off your system because then instead of
preloading IE you preload Moz.
Brian, either you're kidding or you have a much faster computer than most of us.
Startup times are much slower than Netscape Navigator 4.7x, and not even close
to that of IE.
The times to load mozilla, netscape4 and opera vary.  However, mozilla on 
windows will be swapped out if it isn't active, the result is that preloading 
mozilla dll's is relatively useless because windows will kick them out of ram 
(just like it kicks the ie ones out).

It takes mozilla a rather long time to recover from this, i haven't done 
serious time tests of this, but it seems we could reach a point where launching 
mozilla is nearly as fast (or possibly faster?) than windows retrieving the 
libraries from disk.

clearing nsbeta1, because no netscape engineer has offered to work on this 
silly bug.
Keywords: nsbeta1
It isn't just the time of getting libraries copied from disk into RAM; the whole
init process is very slow.
Keywords: nsbeta1
Blocks: 71780
assign to rick now.  he has done some good work regarding to this isssue.
Assignee: nobody → rickg
brainstorming notes from past performance meetings

revisiting the pre-loading mozilla idea:
- how is start-up crash going to impact, if we do pre-loading 
- understand the nature of the start-up problem users are seeing 
  user start-up multiple times a day vs. turning on 
  computer 1st time in the morning is low 
- figure out pre-loading or load less 
- prove kandrot's hypothesis (lots of disk activity due to dll is still 
  being bought into physical memory as we executing code or read DLL) 
- how long it takes for embed shell to start 
- are we reading whole bunch of files in poor faction?
- what happens to dll's private date?  do they get a new set when moz invoke 
  those dlls?
- what about combining all dlls into one?

pre-loader service related issues:
- how does SmartUpdate/Installer going to shutdown and update files? any
  programmatic way to show down?
- how to install service manager? 
- what happens if multiple copies of moz from different venders all need to
  install this service?  do we have multiple services or single?  what do we
  do/decide who gets loaded? what needs to be done?

Here's an update. I've finished the .exe version of the preloader. It can load 
modules for ns6, ns65 or mozilla/debug (and is somewhat configurable). 

I did some adhoc testing on 3 machines (cited below). I'm not sure I got all the 
right modules (or the best order), but it's starting to move the needle on 
startup time. On a fast machine with lots of resources, you can expect a MAJOR 
speed up (mine went from 18 to ~3 seconds). Slower machines and less powerful 
OS's (like win95) don't benefit as much; 20-25% seems average.

The following results were taken from a mozilla/debug build. I modified the 
build so that each module has an added function (GetVersion()) which I call 
repeatedly to keep the module in memory (to prevent paging). It seems this 
approach *may* lead to an improved startup time.


Config                Mozilla       PreLoader+Mozilla
------------------------------------------------------------
win2k;128Mb;733Mhz      18sec            3.5sec
win95;32mb;266Mhz       65sec            45sec
win98;128Mb;500Mhz      30sec            24sec
Status: NEW → ASSIGNED
I've tried to attach the source, but bugzilla seems to be whacky. 
I'll try again on monday.

Rick
D'oh, that's a weekend of eager anticipation.

The GetVersion() looks nice, is it enough to overcome Win2k's automatic swapping 
of DLLs not in use? I don't know how Windows handles that, in fact, timeless was 
the first person I heard it from, so I don't know exactly how it operates. But 
if that is enough to make it resident full time, that's great news.

I was pretty much with boberb, probably spoiled by my 866mhz 192mb RAM Win2k 
machine, because Mozilla loads nearly as fast as 4.x, if not faster (I have 
never timed the two until now, when I don't want to lose all my work). But so 
long as someone's aleady wrote the code for it, I'm all for it now. I just wish 
we didn't have to wait until Monday for the source or compiled executable :(
It seems I can't attach files from my machine, but attinasi can, so he just 
attached the source to the preloader. By default, the preloader works with 
modules from 6.5, or 6.0 (whichever it finds in your registry). If you want to 
use it with a debug build (mozilla) use the command line args:

-d (use debug modules)
-p <path>  (to tell it where your modules live).
Is it supposed to work with Mozilla installed with the Mozilla installer?
Looking at the source it only tries to find the path in the registry from:
Software\\Netscape\\Netscape 6\\6.0 (en)\\Main";
Software\\Netscape\\Netscape 6\\6.5 (en)\\Main

and not look at the registry key used by the Mozilla installer:
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla.org\Mozilla\0.8 (en)\Main
Install Directory=

The "0.8 (en)" subkey name can be found at:
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla.org\Mozilla
CurrentVersion=0.8 (en)
I didn't use the mozilla installer, and I didn't add a case to handle the 
registry entries it might use. But I did add command line args that let you tell 
me where to find your source directly (see my prior comment).

Adding entries for the mozilla registry would be trivial, given the pattern that 
I've already implemented. Care to take a crack at it?
For the preloader to work, you have to have an instrumented version of mozilla. 
(Each module needs to export GetVersion()). My build has that, but it's not 
checked in as of yet. Hopefully we'll get that approved in this week's 
performance meeting. Stay tuned.
Mathew: I don't get it - my computer stinks yet my startup time is less than a 
second.
I have Windows 2000 PII 366 IBM thinkpad with 294 megs of ram. Even when I had 
only 128 megs of ram it loaded in less than a second. Can it actually take 18 
seconds to load? If it does, it sounds more like a bug than the norm. Maybe 
there is something on those people's computer making it load so slowly instead 
of Mozilla being inherently slow.
I beg to differ. I have discussed with quite a few Mozilla users and many have 
quit using mozilla for the sole reason of extremely long intitialization times. 
The general consensus is that mozilla is the slowest browser, even slower than 
Netscape 4.7, and this has been true since I started testing in 0.6
I have tried numerous computers from PIIs of 128 mb ram to PIII800s and never 
had a problem. The only time I had a problem was with a 486 laptop with 4 mb 
ram. Since every computer I ran Mozilla on had at least 128 mb ram, I would 
assume that memory is actually what makes it slow on startup and these people 
don't have much ram installed. I'm going to make a post on the newsgroup asking 
information about people's setups that have slow initiations.
My setup:
AMD Athlon 650 / 128 MB RAM / Win98
rickg: could you perhaps let leaf or someone upload one of your builds to the
ftp server for us to test? this was done with the new-cache rewrite and helped
find issues with it.
It's slow at work on a PIII 450 with 256MB of RAM under Linux (10 seconds
startup) and even slower at home on a dual PII 266 with 192MB under both Windows
and Linux (20 seconds under Linux, more under Windows).
Thats why I'm beginning to think something fishy is going on thats causing it 
to be slow on certain computers. It doesn't make sense that someone with a 
better computer than some of the ones I've had no problem on have a problem. 
The staying resident will mask this problem but won't actually solve it. I have 
heard many stories of people not being able to run Mozilla and Netscape 6/6.01 
and also of it taking forever to load, and I think there is something weird 
going on.

For instance, my mom's Pentium MMX computer with 128 MB Ram has no problem. It 
loads in about 2 seconds.
Do you have a recent build? btw... 2 seconds might have been a little bit of a 
stretch.
This is with "official" nightly builds, milestone releases, Christopher
Blizzard's Linux RPMs, and my own Linux builds.

I've tested it on half a dozen other computers, with
similar results. In fact, I'd go so far as to say you're the only person
I've ever heard say that mozilla loads in under 5 seconds on any system.
Not that I wouldn't be happy for you to be right. :)
Is loading just the time for it to show the Mozilla Profiles box (which is 
about 3 seconds)? It is about 3 more seconds after that if you include after 
the dialog until the window is done displaying.
Ah. I'm counting from the time I hit enter until the time I have a usable
browser window. I'm using only one profile, so that window never comes up.
Actually loading a home page adds a fraction of a second; going to "about:blank"
takes (with a build from this morning) 9.5 seconds.

(I should also mention that this is with a really fast SCSI drive, so that's not
a factor.)
For comparison: Netscape 4.76 is at this point in 3 seconds, and Skipstone in 5.2.
Rick,

Could you check your changes into CVS but not part of the build?
Matthew Miller: oh linux, there's your problem. linux memory usage 
requirements are higher because X sucks [this is not just my personal opinion, 
i'm pretty sure i'm quoting a lot of serious developers]. please double all 
memory numbers and try again. [estimated cost ~$30+s/h]
Timeless -- that's a ridiculous troll that I probably shouldn't bother even 
responding to, but I will anyway. 

First of all, your basic assertion isn't true at all.

But overlooking that for a minute: at home, X takes up about 26MB. Mozilla takes
up 20-something at the highest point while loading, plus another 20 for the
java_vm. There is ZERO swap used the entire time, and there's plenty of free
memory the whole time as well.

Please, bugzilla isn't the place for this kind of silliness.
Are these numbers like 2 seconds for the first run or subsequent runs?
Mathew Miller:
I suggest you use a little more restraint using the word "troll" - it is a very offensive word and definately shouldn't be said to someone who has spent such a long time on the project. It severely offends me.

Notes: I don't think we should talk about speed issues in this bug report anymore and therefore I have posted to the newsgroup about this. I am just saying my opinion (which is possibly not wanted) that I think the time spent on this could be better spent on increasing performance on the problematic systems.

BTW: I am using a firewire hard drive when I run Mozilla.
I'm sorry if you're offended, but I know what "troll" means and that was one.
Been a long-time contributor is no excuse -- it just means the poster should
have known better. They obviously hadn't actually read my posts; just keyed in
on the word "Linux" and spit out some irrelevant slander. If anyone has any more
on that, please e-mail me instead of posting, because as I said, it really
doesn't belong here.

For what it's worth, I'd mostly like to see this feature on Win32, which in my
experience is slower at loading Mozilla. I'm not as interested in having it on
Linux.
*** Bug 74657 has been marked as a duplicate of this bug. ***
Rickg's GetVersion trick sounds very aggressive.  If multiple apps did that, 
they would keep fighting to keep their DLLs in memory, and the hard disk would 
never stop thrashing after starting the computer.

I like Peter Lubczynski's approach better -- read the prefs file and initialze 
whatever needs to be initialized, but just don't bring up a browser window.  If 
the operating system thinks it's appropriate to page the DLLs, it probably is.

Anyone for making this a metabug and filing two new bugs for those two mostly 
orthogonal ideas?  (Btw, another idea: keep a hidden browser window around with 
about:blank loaded, and when you need a new browser window, make that window 
appear and use it.)
cc'ing PAW per waterson's request.
*** Bug 75207 has been marked as a duplicate of this bug. ***
see also bug 75599 (that has a possible fix for this too).
Attached file Latest update
The newly attached version removes dependency on other (non-licensed) code. It 
also adds menu options to configure the preloader (which aren't active yet) and 
an remove the preloader from the startup folder (which works). 
Depends on: 76004
I've updated the source again (dprice, do you want me to land this stuff in the 
tree?). 

The new version offers the following changes:
 1. It prevents multiple instances of itself from running concurrently
 2. It wont "ping" the modules if the browser is already running
    (And it changes the systray icon to a yellow gecko).
 3. The GUI is now available to configure (tune) the preloader

I'll add code tomorrow to use the tuning settings, and then the preloader 
should be ready for widespread testing.
 
Attached file Tuesday update
I've updated the preloader in the following manner:

1. More strings are in the resource file
2. Menu has TBM_RIGHTBUTTON flag
3. Tooltip is improved (and in resource file)
4. Config settings are now stored/retrieved from registry
5. Module% and Frequency% config settings are now operational

TBD: I'll hook up the entrypoint% config setting on thursday.

WARNING: I've not tested this version as much as I usual due to a time 
constraint. I don't recommend widespread usage until after thur's version.
This is win only? right?
this fix is, but the bug is not, so someone should decide whether we should 
create additional bugs for other platforms (I think that we should if anyone 
intends to work on them).
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
I see little to no need for it on Linux -- in my mind, this is mostly an
Internet Explorer parity issue to shut up people (like my wife!) who keep saying
"Why use mozilla when IE is ready to go in 1/10th the time?".
"Why use Linux when Mozilla loads three times as quickly on Windows?"
Heh. Hadn't considered that. Maybe you're right....
Why are conversations going on in both this and bug 76004?  Aren't they the same?
Whiteboard: [nav+perf]
QA Contact: sairuh → paw
Blocks: 104166
Err, can we resolve this bug as fixed and send it to its graveyard? Linux
preloader issues should IMHO be discussed in another bug if not yet existing.
reassign to cathleen to close this out, if appropriate
Assignee: rickg → cathleen
Status: ASSIGNED → NEW
QA Contact: paw → hong
we've got turbo mode working.  won't be doing a different kind of pre-loading.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Whiteboard: [nav+perf] → fixed in bug 75599 using a different strategy
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: