Stay resident in order to load faster



UI Design
18 years ago
3 years ago


(Reporter: Jesse Ruderman, Assigned: Cathleen)


({helpwanted, perf})

helpwanted, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: fixed in bug 75599 using a different strategy)


(7 attachments)



18 years ago
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.

Comment 1

18 years ago
adding helpwanted keyword to see if anyone will pick this up and reassigning to where helpwanted bugs live
Assignee: asadotzler → nobody
Keywords: helpwanted

Comment 2

17 years ago
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

Comment 3

17 years ago
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.

Comment 4

17 years ago
might depend on bug 50424.

Comment 5

17 years ago
*** Bug 48846 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
*** Bug 54826 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
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.

Comment 9

17 years ago
*** Bug 64141 has been marked as a duplicate of this bug. ***


17 years ago
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?


17 years ago
Keywords: nsbeta1

Comment 12

17 years ago
*** Bug 64814 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago
*** Bug 66166 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
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

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?

Comment 15

17 years ago
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.

Comment 16

17 years ago
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...

Comment 17

17 years ago
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....

Comment 18

17 years ago
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?

Comment 19

17 years ago
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.

Comment 23

17 years ago
*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.

Comment 24

17 years ago
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

Comment 26

17 years ago
perf radar
Keywords: perf

Comment 27

17 years ago
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!

Comment 28

17 years ago
Sorry for the spam, just adding to CC list

Comment 29

17 years ago
I don't believe this is at all desirable under Mac OS and don't advocate it's
application on that platform.

Comment 30

17 years ago
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 

Comment 32

17 years ago
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
( that strips IE off your system because then instead of
preloading IE you preload Moz.

Comment 33

17 years ago
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.

Comment 34

17 years ago
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

Comment 35

17 years ago
It isn't just the time of getting libraries copied from disk into RAM; the whole
init process is very slow.


17 years ago
Keywords: nsbeta1


17 years ago
Blocks: 71780

Comment 36

17 years ago
assign to rick now.  he has done some good work regarding to this isssue.
Assignee: nobody → rickg

Comment 37

17 years ago
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?

Comment 38

17 years ago
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

Comment 39

17 years ago
I've tried to attach the source, but bugzilla seems to be whacky. 
I'll try again on monday.


Comment 40

17 years ago
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 :(

Comment 41

17 years ago
Created attachment 28125 [details]
ZIP with preload app source

Comment 42

17 years ago
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).

Comment 43

17 years ago
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:
Install Directory=

The "0.8 (en)" subkey name can be found at:
CurrentVersion=0.8 (en)

Comment 44

17 years ago
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?

Comment 45

17 years ago
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 
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.

Comment 47

17 years ago
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.

Comment 49

17 years ago
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.

Comment 51

17 years ago
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 

Comment 54

17 years ago
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.

Comment 55

17 years ago
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.

Comment 57

17 years ago
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.)

Comment 58

17 years ago
For comparison: Netscape 4.76 is at this point in 3 seconds, and Skipstone in 5.2.

Comment 59

17 years ago

Could you check your changes into CVS but not part of the build?

Comment 60

17 years ago
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]

Comment 61

17 years ago
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.

Comment 64

17 years ago
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
*** Bug 74657 has been marked as a duplicate of this bug. ***

Comment 66

17 years ago
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.)

Comment 67

17 years ago
cc'ing PAW per waterson's request.

Comment 68

17 years ago
Created attachment 29852 [details]
zip file containing preloader and project file...

Comment 69

17 years ago
Created attachment 30219 [details]
new update that doesn't require any changes to mozilla

Comment 70

17 years ago
*** Bug 75207 has been marked as a duplicate of this bug. ***
see also bug 75599 (that has a possible fix for this too).

Comment 72

17 years ago
Created attachment 31551 [details]
Latest update

Comment 73

17 years ago
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). 


17 years ago
Depends on: 76004

Comment 74

17 years ago
Created attachment 31922 [details]
Monday's update; lot's of changes

Comment 75

17 years ago
I've updated the source again (dprice, do you want me to land this stuff in the 

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.

Comment 76

17 years ago
Created attachment 32062 [details]
Tuesday update

Comment 77

17 years ago
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.

Comment 78

17 years ago
This is win only? right?

Comment 79

17 years ago
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

Comment 80

17 years ago
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?".

Comment 81

17 years ago
"Why use Linux when Mozilla loads three times as quickly on Windows?"

Comment 82

17 years ago
Heh. Hadn't considered that. Maybe you're right....

Comment 83

17 years ago
Created attachment 32980 [details]
latest and greatest preloader

Comment 84

17 years ago
Why are conversations going on in both this and bug 76004?  Aren't they the same?


16 years ago
Whiteboard: [nav+perf]
QA Contact: sairuh → paw


16 years ago
Blocks: 104166

Comment 85

16 years ago
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.

Comment 86

16 years ago
reassign to cathleen to close this out, if appropriate
Assignee: rickg → cathleen
QA Contact: paw → hong

Comment 87

16 years ago
we've got turbo mode working.  won't be doing a different kind of pre-loading.
Last Resolved: 16 years ago
Resolution: --- → WONTFIX


16 years ago
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.