Alfred Kayser Reporter
	Description • 19 years ago

In response to the discussion about the perceived MLK of FF:
> mozillaZine -- Ben Goodger Explains Higher Memory Usage in Firefox 1.5
> 
> Firefox Lead Engineer Ben Goodger has written a weblog post explaining higher
> memory usage in Firefox 1.5 as compared to Firefox 1.0. While acknowledging
> that all versions of Firefox have memory leaks, Ben points out that many
> people are confusing increased memory usage with a memory leak. Firefox 1.5
> caches upto 8 pages, depending upon the amount of memory in the system.
> Disabling this feature would reduce memory usage, at the expense of 
> load time performance during back/forward navigation.
>    February 15, 2006 02:14 AM

Is there possibly a way to release (unreference) the decoded images from the cached page, when the page is not actually displayed (because in history or in an not-active tab), so that the image cache is able to determine whether there is memory shortage and therefor the images need to be flushed from memory (or from X server in case of Linux and friends).

	Jo Hermans
	Comment 1 • 18 years ago

Alfred, would it be possible to "undecode" images in the memory cache, leaving the encoded version inside. Maybe when we go to the next page, and the current page is still in the bfcache, so it would not be yet evicted. Because the size changes, it will end up in a different pool, but I think it should inherit the fetchcount.

Because of the large difference in size between the decoded en encoded images, I think it would be best to keep only visible images in decoded form. This would dratically reduce the memory requirements of the memory cache.

For example : <http://www.mozilla.com/img/firefox/main-feature3.jpg> is 33706 bytes large, but uses 1433800 bytes in the memorycache

	Alfred Kayser Reporter
	Comment 2 • 18 years ago

The encoded version (as received from the network) is cached in the diskCache. The decoded version is maintained in the memory cache.
The idea of the memory cache is to hold, besides all currently referred to items (i.e. displayed in a page) also the decoded image in memory. The maxSize of memCache there defines the maximum size of the cache for images not referred to.
And only images that are no longer referred to can be flushed from this cache.
(Note: the 'decoded' image is the image object used for the display).

What happens with the bfcache is that also images not really displayed still keep a reference (and can thus not be flushed from the cache). 
A more realistic approach is to make these images 'unreferenced' allowing the memCache to flush also images from the bfcache.

This would allow to have better cache management of those images, flushing images from previous pages when needed. Note, reloading images from the diskCache is probably fast enough for 'fastback'.

A simple solution to ensure that only the encoded images are cached (in disk) would be to disable the memory completely (see about:config, memory.cache). 

But then, the bfcache still holds all the images of the previous 8 or so pages (per tabpage!). This is why the bfcache is so costly, and people turn this off.

My proposal is to let the bfcache only keep the 'view' structure, but releases the images (letting the memoryCache decided to keep them or not).

	Jo Hermans
	Comment 3 • 17 years ago

see also bug 386377

	patrickdrd
	Comment 4 • 17 years ago

[quote="chob"]
People have filed such bugs, as long ago as 2003, and still there has been no action on them:[list][*][url=https://bugzilla.mozilla.org/show_bug.cgi?id=194296]#194296[/url] [Core:Networking: Cache]-minimize memory cache size and growth [All]
[*][url=https://bugzilla.mozilla.org/show_bug.cgi?id=213391]#213391[/url] [Core:Networking: Cache]-Necko/Gecko needs to enforce a maximum for total size of image/memory cache [All]
[*][url=https://bugzilla.mozilla.org/show_bug.cgi?id=327280]#327280[/url] [Core:History: Session]-Don't keep decoded images in the bfcache pages [All][/list]Especially regards the first two, At first I thought Fx 1.5 would have such fixes, but no. So my hope turned to Fx 2.0 to include such fixes. But no, so i thought that Fx 3 much get such fixes. But no. So now where do I pin my hopes to? Fx 3.5? Fx 4? Fx 5?

Personally I don't see such memory problem as a big deal, but I close my browser regularly. My main complaint is that I'm sick to **** of hearing about firefox's memory usage ;) and it is a common complaint on forums and sullies Firefox's reputation in some quarters. 

By leaving such bugs untouched over years, Mozilla really sending out the message 'we don't care'. But it's worse than that - it's not like they don't care because they don't understand the problem or know how to address it; in the bugs filed there are technical discussions and ideas of what to do, and it seems that they still don't care anyway! Bug 213391 was even assigned for a while before being set back to NEW.

But anyway, my main point is there /are/ bugs filed that suggest specific ways firefox could better manage its memory, and absolutely nothing has been done for such bugs. Firefox's memory usage is a definite mark against it when comparing it to other browsers, and it needn't be such a big issue. Mozilla need to give these bugs some serious consideration when the next release cycle is coming around and give people another reason to be proud of firefox.[/quote]

	Jo Hermans
	Comment 5 • 17 years ago

(In reply to comment #2)
> What happens with the bfcache is that also images not really displayed still
> keep a reference (and can thus not be flushed from the cache). 
> A more realistic approach is to make these images 'unreferenced' allowing the
> memCache to flush also images from the bfcache.

If someone wants to debug that, look at my bug 387713 for a proposal. It enhances about:cache to display the inUse-status of an image.

Too bad that about:cache doesn't display some information about the bfcache - it's now impossible to see which pages are in the bfcache or not. Not that the 'memory cache device' in about:cache only contains images.

The biggest problems that we used to have was that some images were always marked as 'inUse', so they could never be flushed. But the latest trunk is much better in this area, especially when you close tabs. It's not totally disappeared though, but it's much harder to trigger it. I had a massive leak 2 days ago, but I couldn't repeat it anymore last night.

	Steve Chapel
	Comment 6 • 17 years ago

Now that bug 296818 is fixed, the decoded images on pages not currently displayed are flushed from memory within less than a minute. That effectively fixes this bug, unless someone is proposing that as soon as a user clicks on a link, that all decoded images are immediately flushed from the page the user just left. It seems to me that either this bug should be marked as a dupe of bug 296818, or the summary of this bug should be changed, for example, to "immediately discard decoded images in the bfcache pages".