Smaller memory footprint for Mozilla?
Adam J. Richter
I am expoloring using mozilla as the principal interface for
installation of our Linux distribution. One problem that I am facing
in this is the size of mozilla's memory footprint. The June 4 Mozilla
snapshot compiled with lesstif uses 13.5MB of memory to start. A
machine with 20MB of RAM locks up when attempting to start mozilla
under X with a window manager present. We will probably shave a
couple of megabytes in shrinking some of the ramdisks that the CDROM
boot process uses, but this would still get us nowhere near being able
offer this interface on an 8MB machine, and it makes installation on a
16MB machine look pretty bleak too.
Simply having a lot of shared libraries mapped into the
executable should not be a problem. I am concerned about the memory
being used that is not simply mapped to the disk. So, I am more
concerned about what is allocating all of this private memory. If
there are any simple ways to build a mozilla that substantially less
memory, I would be interested in hearing about them.
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
ad...@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
Gregory R. Block
> Simply having a lot of shared libraries mapped into the
> executable should not be a problem. I am concerned about the memory
> being used that is not simply mapped to the disk. So, I am more
> concerned about what is allocating all of this private memory. If
> there are any simple ways to build a mozilla that substantially less
> memory, I would be interested in hearing about them.
Part of the problem is, as yet, there aren't enough shared libraries in use. :)
NGLayout may or may not improve the situation, and would certainly provide, at
minimum, a core layout engine which you could embed in an installer that had less
overhead.
As an aside, you could try building a non-debug or strip the socks off of the
whole thing. You could try playing with optimiser settings to reduce the size, as
well.
Anyways, help may not be here yet, but it's coming.
:plur,
Greg
Jamie Zawinski
Gregory R. Block wrote:
>
> Adam J. Richter wrote:
>
> > Simply having a lot of shared libraries mapped into the
> > executable should not be a problem. I am concerned about the memory
> > being used that is not simply mapped to the disk. So, I am more
> > concerned about what is allocating all of this private memory. If
> > there are any simple ways to build a mozilla that substantially less
> > memory, I would be interested in hearing about them.
>
> Part of the problem is, as yet, there aren't enough shared libraries in use. :)
Uh, no -- for Adam's purposes, static linking shouldn't make a
difference, since all those pages are on disk (read-only, shared)
already. He's talking about *heap* usage, not code size.
> NGLayout may or may not improve the situation,
Doubtful, since the layout module is only a part of what makes a web
browser.
> As an aside, you could try building a non-debug or strip the socks off
> of the whole thing. You could try playing with optimiser settings to
> reduce the size, as well.
Won't affect heap at all.
> Anyways, help may not be here yet, but it's coming.
Who's working on reducing heap usage? I don't think anybody is right
now. XP-COM doesn't really address this problem, either.
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
Bert Driehuis
Jamie Zawinski wrote:
> Who's working on reducing heap usage? I don't think anybody is right
> now. XP-COM doesn't really address this problem, either.
This has been high on my todo list for some time now. Unfortunately,
real work interfered :-(
In a not too distant past, I wrote a malloc replacement for VMS that
actually enabled you to account for malloced memory, and charge it to
the module that uses it. Such a thing would at least give insight into
where we should look for optimizations (or #ifdeffing expensive code, in
the case of a Mozilla used for tight memory environments).
Unfortunately, the NSPR/XP schism makes this harder than it should be in
an ideal world. Just out of curiosity, why is one half of the code using
malloc and the other half XP_NEW?
Or is my vision skewed from spending too much time to actually get
Mozilla to link? :-)
[BSD/OS 3.x doesn't like Mozilla redefining malloc(), and that's the
part that was hardest about the VMS malloc way back then as well.
History repeats.]
Cheers,
-- Bert
--
Bert Driehuis, Compuware MIS -- drie...@playbeing.org --
+31-20-3116119
The grand leap of the whale up the Fall of Niagara is esteemed, by all
who have seen it, as one of the finest spectacles in nature.
-- Benjamin Franklin.
Ramiro Estrugo
Adam J. Richter wrote:
>
> I am expoloring using mozilla as the principal interface for
> installation of our Linux distribution. One problem that I am facing
> in this is the size of mozilla's memory footprint. The June 4 Mozilla
> snapshot compiled with lesstif uses 13.5MB of memory to start. A
> machine with 20MB of RAM locks up when attempting to start mozilla
> under X with a window manager present. We will probably shave a
> couple of megabytes in shrinking some of the ramdisks that the CDROM
> boot process uses, but this would still get us nowhere near being able
> offer this interface on an 8MB machine, and it makes installation on a
> 16MB machine look pretty bleak too.
>
> executable should not be a problem. I am concerned about the memory
> being used that is not simply mapped to the disk. So, I am more
> concerned about what is allocating all of this private memory. If
> there are any simple ways to build a mozilla that substantially less
> memory, I would be interested in hearing about them.
>
> Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
This is an interesting topic.
We are so focused on getting mozilla to be "stable" that we really have
not addressed this. At least not to the extent that solves your
particular problem.
First of all, the shotgun modularization and sanitization that mozilla
experienced as part of its source release, has indeed lowered the memory
footprint - by a measurable amount. "Measurable" in that it starts up
faster and it is debuggable with having an infinite amount of memory.
It "feels" faster. I build and debug both mozilla and communicator 4.0x
on a daily basis, and I can for sure say that Mozilla is much smaller.
This makes sense since a lot af heavy components were basically yanked,
such as java, security, mail. Lots of things are yanked. We are now
working on re-introducing these components in a reasonably modularized
fashion.
As for your question:
There is probably not a single magic thing you could tweak to reduce
memory footprint. Its probably a combinations of things (everything
most likely).
The bottom line is that Mozilla does a lot of things, and allocates a
lot of memory on the HEAP to do these things.
Since memory allocated on the HEAP is the problem, dynamic linking
hacks, pluggable components, and other "good" modular schemes wont help
much.
Also, Mozilla exercises a lot of code in many of the components it
uses. For instance, Motif - which has traditionally been blamed for
bloat.
There is probably a scientific way to go about this. Start by profiling
Mozilla, maybe using instrumented malloc() functions that keep track of
who allocates the most memory and why. It might be entirely possible
that a particular module's usage of memory is as good as it gets.
You could then attack the modules that "seem" to be allocating the most
memory. It might be impossible to get rid of these modules - they might
be completely wired throughout the code.
You could also work on the libraries that Mozilla uses. Since you have
the source code for lesstif, a "lesstif lite" project might be worthy
cause.
You could remove things (whole widgets for example) from lesstif
incrementally and see if Mozilla still links. You wont be able to get
rid of major components, such as text fields, but you might be able to
do away with drag/drop, localization, etc.
This all depends on how cleverly engineered lesstif is. If it is
anything like the real motif, then this is a suicidal mission.
BTW, all this rambling is pure guesswork.
But, I've actually written some code that reduces the memory footprint
of Mozilla significantly. A lot of this code is ready to go, minus a
few tweaks. This code was inspired by the lucrative x terminal market
which loves to hate Mozilla.
What I did is added resources to selectively turn off "chunks" of the
chrome. For example, in a resource file you could have:
Netscape*personalToolbar*isEnabled: False
Netscape*componentBar*isEnabled: False
It might sound trivial, but it actually saves a reasonable amount of
memory. If you add up a bunch of these "chunks", the savings could be
significant, especially if you consider that the personal toolbar might
create whole window hierarchies. Rememver that not allocating a Widget,
saves memory both in the client and in the server.
Most of the chrome you see on the navigator could be turned off in this
fashion. It would not be hard at all to make this mechanism all
inclusive. The mechanism is in place. A lot of the work is simply
adding an additional condition before creating a component and making
sure Mozilla still runs.
There are other tweaks that can be made. For instance, I found that by
reducing the gratuitous usage of Pixmaps in toolbars (for all the magic
effects), X server memory on a 24 bit server could be reduced by a lot
(where a lot was about 1 meg, i think). Instead of using an insensitive
pixmap, I rendered the insensitive effect. Same for the armed effect.
This code is already in mozilla. The way icons are allocated in Mozilla
needs further tweaking. In fact, we can safely say it is broken, since
it allocates icons whether needed or not. There is a good reason for
this: schedule.
I think it might be a worthy project to make the above mechanism work
for more components. But, we might discover that the savings (even
though significant) are still not the majority of the memory allocated
by mozilla.
-re