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

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 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

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 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.

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 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

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).

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).

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.

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....

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.