A faster Boot up for Communicator
Sandeep Hundal
Since one of the principal complaints about Communicator are that it
boots up much more slowly than IE, isn't there a remedy for this ? How
about this ideas ?
1) Load up some files at the beginning. This can be done like MS office
i.e. insert a file in the Start Up program group which can be deleted by
advanced users if they wish. But for a newbie, it would just mean a
slightly slower bootup and a slightly faster Netscape Start.
Yeah I know its not fair on the User but hey MS does it, why can't
Netscape ?
2) Seperate the Suite. If I just want Collabra and Navigator, or just
Composer along with Navigator, I should be able to just include them in
the installation, with a setup option to include or remove them later.
That should make things faster for people just interested in a few
programs.
3) Avoid loading plug-ins at the beginning. The point here is that
typically a newuser will install all nice looking/sounding plugins for
his/her Navigator, and when the time comes to load the browser, it will
take time. If there was a way of simply loading plug-ins when they're
needed, it would be better specially since people don't use all their
plug-ins all of the time....
Thanks for listening to my rantings :)
Michael Judge
In response to #1, we actually kicked this idea around for a while and
decided that that
was a "wrong" thing to do. Perhaps this will change, but the idea was that
we are trying to be the good guys and we don't want to put any more crap in
the users startup. Again, this is my take on it.
As far a #2 is concerned, I dont think the benefit from loading or not
loading Composer for example it that beneficial since (for the time being)
Composer is so integrated into the layout engine.
#3 I believe we are working on that. There is a guy here who has done that
for the composer plugins. Maybe we can get him to do this for normal
plugins. I am really not the person to ask about this on the technical
issue.
Cool
Mike Judge
Sandeep Hundal wrote:
Sandeep Hundal
>In response to #1, we actually kicked this idea around for a
while and
>decided that that
>was a "wrong" thing to do. Perhaps this will change, but the
idea was that
>we are trying to be the good guys and we don't want to put any
more crap in
>the users startup. Again, this is my take on it.
I accept that. Even now, Netscape is practically the only company I
trust with software and what they do to my computer. Definitely not MS.
But the problem is that times are getting a bit rough, and you guys need
to cut some corners specially with the arrival on Win98. Now that OEM's
have started (slowly) offering both the browsers together, a slow
startup could still mean that the Newbie decides to use IE more often.
After all, if Users want to get rid of it, then can easily. All you're
doing is loading some DLL's into memory early on.
>As far a #2 is concerned, I dont think the benefit from loading
or not
>loading Composer for example it that beneficial since (for the
time being)
>Composer is so integrated into the layout engine.
Also, accepted, but I think the trend is to move away from Bloatware,
and I hate to admit it but NC4 comes under this category. You need to
give more customizable options when installing.
>#3 I believe we are working on that. There is a guy here who
has done that
>for the composer plugins. Maybe we can get him to do this for
normal
>plugins. I am really not the person to ask about this on the
technical
>issue.
Great ! But I'm not asking for the technical details, I'm kinda
suggesting it to the group. I look at from an end user's point of view,
don't have the time (or ability) to (learn to) code.
Thanks for listening :)
Daniel Veditz
Sandeep Hundal wrote:
>
> > As far a #2 is concerned, I dont think the benefit from loading or
> > not loading Composer for example it that beneficial since (for the
> > time being) Composer is so integrated into the layout engine.
>
> Also, accepted, but I think the trend is to move away from Bloatware,
> and I hate to admit it but NC4 comes under this category. You need to
> give more customizable options when installing.
We are also working on that, but step by step. The NGLayout is the first
fruits of our modularization strategy. That will have to be finished and
swapped into Mozilla before we can start breaking out the pieces that
depend on layout.
We all want the same thing you do on this.
-Dan Veditz
Gregory R. Block
> I accept that. Even now, Netscape is practically the only company I
> trust with software and what they do to my computer. Definitely not MS.
> But the problem is that times are getting a bit rough, and you guys need
> to cut some corners specially with the arrival on Win98. Now that OEM's
> have started (slowly) offering both the browsers together, a slow
> startup could still mean that the Newbie decides to use IE more often.
> After all, if Users want to get rid of it, then can easily. All you're
> doing is loading some DLL's into memory early on.
And more importantly, some of us know exactly what we're putting into our
startup folders, and wouldn't mind the ability at all, since we spend most
of our day with the damn thing running *anyways*. :)
Still, if there are other solutions (and there are) which yield better
results (and they will) a quick-and-dirty fix of a startup-application
probably isn't the way to go.
> Also, accepted, but I think the trend is to move away from Bloatware,
> and I hate to admit it but NC4 comes under this category. You need to
> give more customizable options when installing.
Moving things toward XPCOM will help, but XPCOM isn't a magical remedy.
XPCOM doesn't tell you *how* to modularise; it doesn't tell you how composer
should be written to use a more portable layout system, it merely offers the
possibility. So there's lots that can be done by people in the way of
suggestions and analysis of the problem, and there's lots that's being done
on this by the nglayout people now.
Anyways, ultimately, modules are the way to go, yes.
> Great ! But I'm not asking for the technical details, I'm kinda
> suggesting it to the group. I look at from an end user's point of view,
> don't have the time (or ability) to (learn to) code.
Well, everyone has the ability, IMO, but that's a philosophical issue
regarding complexity and mental capacity vs. the nature of
education/learning and our internal representation of knowledge. Not really
appropriate to the newsgroup. I do, however, appreciate where you're coming
from on the issue, as a user. :)
:plur,
Greg
Benjamin Redelings I
I seem to remember hearing that a significant part of the startup time is
actually just netscape checking its cache files. This may perhaps be only
a UNIX problem... I think I remember hearing that it results from the fact
that netscape considers UNIX directories to be 'changed' if the access time
(ATIME) alters, even though the modification time (mtime) stays constant...
-BenRI
Greg Stark
That could well be a major factor. This is worth profiling and checking.
Opening many files in a large directory can be very inefficient. In
the common implementation each name lookup is a linear search through
several blocks. This is one of the main reasons mh and similarly
designed systems are very slow on many architectures.
greg
Jamie Zawinski
Greg Stark wrote:
>
> Opening many files in a large directory can be very inefficient. In
> the common implementation each name lookup is a linear search through
> several blocks. This is one of the main reasons mh and similarly
> designed systems are very slow on many architectures.
And this is why ~/.netscape/cache/ has 32 subdirectories, with the
cached documents distributed evenly among them: to keep the number of
files per directory down.
If you assume a 5M cache, and an average of 2k per document (which is
probably low) that leaves you with only 80 files per directory over
which the system has to search linearly, instead of 2500.
I don't know details of the cache directories on Windows and Mac, or
of the Windows or Mac file systems.
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
TenThumbs
Greg Stark wrote:
>
> Benjamin Redelings I <bred...@ucsd.edu> writes:
>
> > I seem to remember hearing that a significant part of the startup time is
> > actually just netscape checking its cache files. This may perhaps be only
> > a UNIX problem... I think I remember hearing that it results from the fact
> > that netscape considers UNIX directories to be 'changed' if the access time
> > (ATIME) alters, even though the modification time (mtime) stays constant...
>
> That could well be a major factor. This is worth profiling and checking.
>
> the common implementation each name lookup is a linear search through
> several blocks. This is one of the main reasons mh and similarly
> designed systems are very slow on many architectures.
>
I don't think this is the problem. I hacked together a program to read a directory tree
and, at worst, it only took a few hundred milliseconds on /usr/bin which has 562 files
init. Furthermore, if this really is an issue, then it would appear on shutdown as well,
see NET_CleanupCacheDirectory, and would also occur in 3.0 because I believe the code is
essentially the same. 3.0 shuts down quite quickly even though there is a really ancient
silly bug in Unix.
Martin Nilsson
Benjamin Redelings I wrote:
>
> I seem to remember hearing that a significant part of the startup time is
> actually just netscape checking its cache files. This may perhaps be only
> a UNIX problem... I think I remember hearing that it results from the fact
> that netscape considers UNIX directories to be 'changed' if the access time
> (ATIME) alters, even though the modification time (mtime) stays constant...
>
Is it really necessary to check cache at startup in the first place? And
if so, why not make the main window appear before the cache is checked
so that people could begin to write a URL or whatever they want to do.
It will look at lot faster, even though it does the same things.
--
/Martin Nilsson
Michael Blakeley
<sha...@netscape.com> wrote:
>Jamie Zawinski wrote:
>> I don't know details of the cache directories on Windows and Mac, or
>> of the Windows or Mac file systems.
>
>The Mac HFS uses btrees to store directory information, so they're
>pretty quick on the lookup side.
>
>Mike
Mike, that's really not true - at least not over about 100 items per
directory with HFS (I haven't tried HFS Plus yet). IMO, the MacFE would do
well to adopt the scheme Jamie has mentioned.
Personally, I run Communicator with the prefs hacked for a RAM cache, and
_no_ disk cache. It's much faster than the default, even with a 28.8
modem, Power Computing 100, OS 8.1, and 56MB RAM:
user_pref("browser.cache.disk_cache_size", 0);
user_pref("browser.cache.memory_cache_size", 4096);
--
Michael Blakeley mi...@blakeley.com <http://www.blakeley.com/>
Performance Analysis for Internet Technologies