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
email@example.com where helpwanted bugs live
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
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. ***
[Fixing OS that mpt messed up...]
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?
*** 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
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
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.
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
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 :)
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
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
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
It isn't just the time of getting libraries copied from disk into RAM; the whole
init process is very slow.
assign to rick now. he has done some good work regarding to this isssue.
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
- 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
I've tried to attach the source, but bugzilla seems to be whacky.
I'll try again on monday.
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 :(
Created attachment 28125 [details]
ZIP with preload app source
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:
The "0.8 (en)" subkey name can be found at:
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
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.
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
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
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
For comparison: Netscape 4.76 is at this point in 3 seconds, and Skipstone in 5.2.
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?
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
*** 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.
Created attachment 29852 [details]
zip file containing preloader and project file...
Created attachment 30219 [details]
new update that doesn't require any changes to mozilla
*** Bug 75207 has been marked as a duplicate of this bug. ***
see also bug 75599 (that has a possible fix for this too).
Created attachment 31551 [details]
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).
Created attachment 31922 [details]
Monday's update; lot's of changes
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.
Created attachment 32062 [details]
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).
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....
Created attachment 32980 [details]
latest and greatest preloader
Why are conversations going on in both this and bug 76004? Aren't they the same?
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
we've got turbo mode working. won't be doing a different kind of pre-loading.