[geeks] Firefox, affect of cache capacity settings

[Charles Shannon Hendrix]

I made changes to the Firefox configuration to force a low limit on
memory cache capacity.  I set the value to 4096 (4 megabytes).

I ran the same set of tests--loading certain saved bookmark sets and
doing some operations on the pages--and after repeating and also running
Firefox for almost 24 hours, it appears that this has reduced short-term
runaway memory usage.

I'm going to keep my configuration set at 4MB, because I didn't really
notice any problems with chrome elements or images causing the rendering
to slow down.  However, you might want to experiment because some people
say that a few pages will want more, like that Web 2.0 stuff.

Notes about long term memory usage:

This remains a problem.  I used tabs to push Firefox to about 180MB and
stopped.  I then unloaded all but a single blank Window.  Of course, I
didn't expect the memory cache to fix this because it is primarily a
limit of how much memory to use for cached chrome elements and image
data.

Firefox never deallocated more than about 2% of the now unused data,
even almost a full day later.

NOTE: if you trace Firefox, make sure you have a lot of space for the
trace files.  On my Linux box it makes about 110 library and system
calls per second when idle, more when working.

Firefox assumes it can allocate a certain amount of memory based on how
much memory your machine has, even if you don't want it to, or even if
that's going to result in poor performance.

The arguments against this first came up in 2000 (you can check both
bugzilla and the mailing lists).

What happens is this: Firefox allocates objects, and until it reaches a
fairly high and somewhat vague allocation limit, it does not start
culling old allocations, even if they haven't been used in days.

For example, when you close a tab, Firefox doesn't release the memory.
In fact, it doesn't even call free().  This causes Firefox to ask for
more virtual memory rather than using what is already allocated and
unused.

The theory is that if you have a lot of RAM, it won't matter.

The other issue is that when a tab is closed on a page that has periodic
dynamic element updates, it will continue to allocate memory even though
you aren't even seeing the page.  This is a bad memory leak, which I
think has been fixed at least partially.

What was talked about 6 years ago was letting Firefox deallocate and
reuse memory, and even call unmap() to permanently remove pages when
pressure is low.  Since UNIX never automatically shrinks your VM size,
your application has to specifically ask for that.  In a lot of cases,
careful use of unmap() has huge benefits.

You can occasionally see Firefox call unmap() but not often, and I think
it might actually be support libraries, not Firefox code.

The complaints about Firefox memory usage are legion, and as a result
the Mozilla team has focused on memory leaks, and fixed a lot of them,
including the last 1.5.0.5 release.

However, I don't believe any fundamental change in its allocation
strategy is coming, or at least not in 1.5.x.

>From what I've read about 2.x, memory usage will increase unless
allocation strategy changes.

I personally would prefer that Firefox allowed me to set my own
allocation limits, and I'd also prefer it to add (more) unmap() code to
its allocation system.  It is quite frequent that I visit pages once and
not again for days or weeks.  Why have that in memory?  I rather use an
external cache for that kind of thing.

Note about the vagueness of memory usage:

That just means that the allocations under a given limit generally
also cause side-effect allocations, so the limits are not absolute.
Programmers understand this, but the users often don't.





-- 
shannon "AT" widomaker.com -- ["That which is overdesigned, too highly
specific, anticipates outcome; the anticipation of outcome garantees, if
not failure, the absence of grace." -- William Gibson, All Tomorrow's
Parties]