Last Comment Bug 36283 - Stay resident in order to load faster
: Stay resident in order to load faster
Status: RESOLVED WONTFIX
fixed in bug 75599 using a different ...
: helpwanted, perf
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: All All
: P3 enhancement with 3 votes (vote)
: ---
Assigned To: Cathleen
: Hong Kwon
Mentors:
: 48846 54826 64141 64814 66166 74657 75207 (view as bug list)
Depends on: 76004
Blocks: 71780 104166
  Show dependency treegraph
 
Reported: 2000-04-18 23:19 PDT by Jesse Ruderman
Modified: 2014-04-26 03:06 PDT (History)
43 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
ZIP with preload app source (13.11 KB, application/octet-stream)
2001-03-19 11:19 PST, Marc Attinasi
no flags Details
zip file containing preloader and project file... (13.78 KB, application/zip)
2001-04-05 14:03 PDT, rickg
no flags Details
new update that doesn't require any changes to mozilla (14.51 KB, application/zip)
2001-04-09 18:37 PDT, rickg
no flags Details
Latest update (12.55 KB, application/zip)
2001-04-19 19:02 PDT, rickg
no flags Details
Monday's update; lot's of changes (13.52 KB, application/zip)
2001-04-23 16:52 PDT, rickg
no flags Details
Tuesday update (15.00 KB, application/zip)
2001-04-24 15:56 PDT, rickg
no flags Details
latest and greatest preloader (20.07 KB, application/octet-stream)
2001-05-02 17:15 PDT, dprice (gone)
no flags Details

Description Jesse Ruderman 2000-04-18 23:19:07 PDT
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 Asa Dotzler [:asa] 2000-04-26 13:33:38 PDT
adding helpwanted keyword to see if anyone will pick this up and reassigning to 
nobody@mozilla.org where helpwanted bugs live
Comment 2 Asa Dotzler [:asa] 2000-06-06 17:25:35 PDT
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
Comment 3 Matthew Paul Thomas 2000-06-11 15:38:14 PDT
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 Jesse Ruderman 2000-08-26 09:39:37 PDT
might depend on bug 50424.
Comment 5 Jesse Ruderman 2000-09-24 05:21:19 PDT
*** Bug 48846 has been marked as a duplicate of this bug. ***
Comment 6 David Krause 2000-09-30 20:22:21 PDT
*** Bug 54826 has been marked as a duplicate of this bug. ***
Comment 7 Zach Lipton [:zach] 2000-10-08 15:59:28 PDT
why not do something on the mac with shared libs like IE?
Comment 8 Brian 'netdragon' Bober 2000-12-17 18:00:07 PST
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 Matthew Paul Thomas 2001-01-02 18:38:56 PST
*** Bug 64141 has been marked as a duplicate of this bug. ***
Comment 10 Hixie (not reading bugmail) 2001-01-02 19:59:04 PST
[Fixing OS that mpt messed up...]
Comment 11 Brian 'netdragon' Bober 2001-01-08 10:07:50 PST
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?
Comment 12 R.K.Aa. 2001-01-09 14:56:43 PST
*** Bug 64814 has been marked as a duplicate of this bug. ***
Comment 13 Stephen Walker 2001-01-21 21:32:57 PST
*** Bug 66166 has been marked as a duplicate of this bug. ***
Comment 14 Peter Lubczynski 2001-02-01 07:07:35 PST
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?
Comment 15 timeless 2001-02-01 08:53:45 PST
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 Marc Attinasi 2001-02-01 09:12:58 PST
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 Peter Lubczynski 2001-02-01 10:14:02 PST
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 timeless 2001-02-01 14:54:43 PST
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 Marcus Pallinger 2001-02-01 16:51:59 PST
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.
Comment 20 Brian 'netdragon' Bober 2001-02-05 02:16:25 PST
Mozilla loads a lot of junk it doesn't need on startup. IE: Why not load java 
until needed?
Comment 21 Brian 'netdragon' Bober 2001-02-05 02:18:19 PST
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.
Comment 22 Brian 'netdragon' Bober 2001-02-05 14:08:45 PST
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 Marcus Pallinger 2001-02-05 17:26:42 PST
*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 Peter Lubczynski 2001-02-05 17:42:36 PST
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. 
Comment 25 Brian 'netdragon' Bober 2001-02-05 21:40:35 PST
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 Chris McAfee 2001-02-14 19:07:27 PST
perf radar
Comment 27 Peter Lubczynski 2001-02-19 15:31:55 PST
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 Alex Bischoff 2001-03-02 17:12:18 PST
Sorry for the spam, just adding to CC list
Comment 29 Greg K. 2001-03-09 11:04:25 PST
I don't believe this is at all desirable under Mac OS and don't advocate it's
application on that platform.
Comment 30 David Hallowell 2001-03-11 08:51:07 PST
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 :)
Comment 31 Brian 'netdragon' Bober 2001-03-12 03:43:38 PST
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.
Comment 32 David Hallowell 2001-03-12 07:02:43 PST
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.
Comment 33 Matthew Miller 2001-03-12 10:20:15 PST
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 timeless 2001-03-12 12:37:41 PST
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.
Comment 35 Matthew Miller 2001-03-12 12:45:17 PST
It isn't just the time of getting libraries copied from disk into RAM; the whole
init process is very slow.
Comment 36 Cathleen 2001-03-13 18:29:51 PST
assign to rick now.  he has done some good work regarding to this isssue.
Comment 37 Cathleen 2001-03-15 12:41:07 PST
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 rickg 2001-03-16 17:04:23 PST
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 rickg 2001-03-16 17:12:37 PST
I've tried to attach the source, but bugzilla seems to be whacky. 
I'll try again on monday.

Rick
Comment 40 Dan Nunn 2001-03-16 18:34:50 PST
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 Marc Attinasi 2001-03-19 11:19:37 PST
Created attachment 28125 [details]
ZIP with preload app source
Comment 42 rickg 2001-03-19 11:22:45 PST
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 ajbu 2001-03-19 14:05:41 PST
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)
Comment 44 rickg 2001-03-19 14:26:10 PST
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 rickg 2001-03-20 11:09:30 PST
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.
Comment 46 Brian 'netdragon' Bober 2001-03-21 20:22:57 PST
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.
Comment 47 Lewis 2001-03-21 21:06:54 PST
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
Comment 48 Brian 'netdragon' Bober 2001-03-21 21:31:27 PST
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 Lewis 2001-03-21 21:39:42 PST
My setup:
AMD Athlon 650 / 128 MB RAM / Win98
Comment 50 Doron Rosenberg (IBM) 2001-03-22 01:34:39 PST
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 Matthew Miller 2001-03-22 05:31:14 PST
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).
Comment 52 Brian 'netdragon' Bober 2001-03-22 06:12:29 PST
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.
Comment 53 Brian 'netdragon' Bober 2001-03-22 06:20:26 PST
Do you have a recent build? btw... 2 seconds might have been a little bit of a 
stretch.
Comment 54 Matthew Miller 2001-03-22 06:22:48 PST
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 Matthew Miller 2001-03-22 06:32:22 PST
Not that I wouldn't be happy for you to be right. :)
Comment 56 Brian 'netdragon' Bober 2001-03-22 06:39:11 PST
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 Matthew Miller 2001-03-22 06:45:40 PST
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 Matthew Miller 2001-03-22 06:48:42 PST
For comparison: Netscape 4.76 is at this point in 3 seconds, and Skipstone in 5.2.
Comment 59 Peter Lubczynski 2001-03-22 07:32:27 PST
Rick,

Could you check your changes into CVS but not part of the build?
Comment 60 timeless 2001-03-23 00:27:50 PST
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 Matthew Miller 2001-03-23 06:38:14 PST
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.
Comment 62 Christian :Biesinger (don't email me, ping me on IRC) 2001-03-24 04:12:47 PST
Are these numbers like 2 seconds for the first run or subsequent runs?
Comment 63 Brian 'netdragon' Bober 2001-03-29 21:11:43 PST
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 Matthew Miller 2001-03-30 07:55:41 PST
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.
Comment 65 Boris Zbarsky [:bz] 2001-04-03 18:52:44 PDT
*** Bug 74657 has been marked as a duplicate of this bug. ***
Comment 66 Jesse Ruderman 2001-04-03 19:45:44 PDT
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 rickg 2001-04-05 13:48:04 PDT
cc'ing PAW per waterson's request.
Comment 68 rickg 2001-04-05 14:03:11 PDT
Created attachment 29852 [details]
zip file containing preloader and project file...
Comment 69 rickg 2001-04-09 18:37:01 PDT
Created attachment 30219 [details]
new update that doesn't require any changes to mozilla
Comment 70 timeless 2001-04-10 17:28:45 PDT
*** Bug 75207 has been marked as a duplicate of this bug. ***
Comment 71 Boris Zbarsky [:bz] 2001-04-11 15:18:03 PDT
see also bug 75599 (that has a possible fix for this too).
Comment 72 rickg 2001-04-19 19:02:39 PDT
Created attachment 31551 [details]
Latest update
Comment 73 rickg 2001-04-19 19:04:13 PDT
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). 
Comment 74 rickg 2001-04-23 16:52:47 PDT
Created attachment 31922 [details]
Monday's update; lot's of changes
Comment 75 rickg 2001-04-23 16:55:39 PDT
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.
 
Comment 76 rickg 2001-04-24 15:56:08 PDT
Created attachment 32062 [details]
Tuesday update
Comment 77 rickg 2001-04-24 15:59:40 PDT
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 Zach Lipton [:zach] 2001-04-24 18:03:25 PDT
This is win only? right?
Comment 79 timeless 2001-04-24 19:07:26 PDT
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).
Comment 80 Matthew Miller 2001-04-24 19:17:51 PDT
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 Jesse Ruderman 2001-04-25 10:48:54 PDT
"Why use Linux when Mozilla loads three times as quickly on Windows?"
Comment 82 Matthew Miller 2001-04-25 10:53:21 PDT
Heh. Hadn't considered that. Maybe you're right....
Comment 83 dprice (gone) 2001-05-02 17:15:00 PDT
Created attachment 32980 [details]
latest and greatest preloader
Comment 84 Dean Tessman 2001-05-07 13:25:56 PDT
Why are conversations going on in both this and bug 76004?  Aren't they the same?
Comment 85 Sebastian Späth 2001-11-15 03:25:04 PST
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 lchiang 2001-11-21 14:58:40 PST
reassign to cathleen to close this out, if appropriate
Comment 87 Cathleen 2001-11-27 12:37:35 PST
we've got turbo mode working.  won't be doing a different kind of pre-loading.

Note You need to log in before you can comment on or make changes to this bug.