398983 - increased memory usage when viewing page with many pictures

Status: RESOLVED DUPLICATE of bug 683284

(Core :: Graphics, defect, P3)

Description

[bugzilla.mozilla.org]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100705 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100705 Minefield/3.0a9pre

current FF3 nightlies show an increased momory usage when displaying pages with many pictures - compared to Firefox 2.x



Reproducible: Always

Steps to Reproduce:
1. open http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?n=1
2. change n=1 to n=500 to get more images shown
3. save whole page on harddrive
4. restart browser and open the saved page
5. watch memory consumption

(please do 3 and 4 to save bandwidth on the server)

Actual Results:  
resource usage for the 500-images-page as reported by ProcesExplorer on WinXP, each browser started with new empty default profile

Process		Virtual Size	Working Set	Private Bytes	GDI Objects
===========================================================================
firefox-3.exe	1.287.316 K	1.218.596 K	1.206.756 K	1.195	

firefox-2.exe	1.032.032 K	962.420 K	951.612 K	86	

firefox-2.exe	857.308 K	791.640 K	780.532 K	168

the 2nd Firefox-2 is the same page after scrolling once to the very end (scrolling, not using the END" key). Memory usage decreases at the cost of more GDI objects once loaded images get actually shown on screen. 

Resource usage stays the same in FF3 while scrolling the page.




Initially I reported bug 366548 about corrupt rendering on pages with many pictures. Work on bug 381578 seems to have fixed the rendering issue in current nightlies at the cost of increased memory usage.

But memory usage seems to be now quite a bit higher than it is in Firefox 2

Comment 1

[bugzilla.mozilla.org]

ups, mixed up the bug numbers in the sentence above. Please reverse the numbers while reading :)

Comment 2

[Jo Hermans]

might be fixed by bug 296818

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

There are two things going on:

1 - all images use 4 bytes per pixel now; before, jpegs used 3 bytes per pixel.  So that accounts for the memory usage increase.  We can't do much about this -- all the compositing code needs to work with normal dword-aligned pixels, as nothing much (other than GDI) wants to touch packed-pixel bitmaps.

2 - in fx2, we used to lazily stuff images into GDI objects only when they're used.. now we do that right up front.  We also never un-optimize images.  Fixing both of these will wait until bug 296818 is fixed, because we need to make sure that the interaction between the two makes sense.

Comment 4

[Steve Chapel]

I can still reproduce now that bug 296818 is fixed. If the images are stored in the disk cache and I visit the page with 500 images, or if I scroll through the page with 500 images quickly, the memory use goes up to about 1.3 GB with about 1500 GDI objects. If I wait less than a minute, though, the memory use and GDI objects decrease rapidly (this is the effect of the fix to bug 296818).

I note that the page scrolls quickly, even after the decoded images are discarded. This suggests a way to avoid high memory use due to pages with lots of large images:

1) Do not decode all images on the page when the page is first loaded. Instead, wait until each image needs to be displayed, and then decode it. This would limit the memory use when first loading the page.

2) Set the default timeout for discarding decoded images to a much shorter time, say 10 to 15 seconds. This would limit the memory use when scrolling.

These changes should not cause any additional performance problem, as the performance for scrolling through a freshly loaded page would be no slower than scrolling through a page that was loaded more than a minute ago.

Actually, the only performance problem I saw while trying to reproduce was that scrolling the page was very slow after first loading it, presumably because Firefox was busy decoding every image on the page. These fixes might actually end up increasing performance, as well as dramatically reducing memory use on pages with lots of large images.

Comment 5

[Steve Chapel]

Instead of #2 above, why not simply discard decoded images when the image cache capacity is exceeded? That would limit the size of the memory cache and fix bug 213391, and also remove the need for a new preference in bug 399923. In short, why was a timeout used at all, instead of just throwing away the least recently used data when the cache exceeds its capacity, just like the disk cache?

Comment 6

[Mike Schroepfer]

(In reply to comment #3)
> There are two things going on:
> 
> 1 - all images use 4 bytes per pixel now; before, jpegs used 3 bytes per pixel.
>  So that accounts for the memory usage increase.  We can't do much about this
> -- all the compositing code needs to work with normal dword-aligned pixels, as
> nothing much (other than GDI) wants to touch packed-pixel bitmaps.
> 
> 2 - in fx2, we used to lazily stuff images into GDI objects only when they're
> used.. now we do that right up front.  We also never un-optimize images. 
> Fixing both of these will wait until bug 296818 is fixed, because we need to
> make sure that the interaction between the two makes sense.
> 

Now that 296818 is fixed should we take another pass at this?

Comment 7

[Alfred Kayser]

This is 'as designed' in FF2 for each pixel in each frame of the image 3 bytes are used. But for FF3 we use Cairo which uses 4 bytes per pixel., so
that easily explains the 25% increase.

However, since my patch (bug 143046) to store GIF animations as 8bit per pixel,
this is now actually less in current FF3 builds: 56392210 bytes = 55K, so that
is actually less than a third of the original 175K. See the latest beta or
nightly of FF3.

So, can the tests of the comment #1 be redone using a fresh build?

Comment 8

[Steve Chapel]

Now that bug 296818 is fixed, the original testcase doesn't consume quite so much memory (about 800 MB when I tried it, but of course that will vary according to how quickly the page is loaded). But if you add the step:

4a. Grab the scrollbar and slowly drag it down so every image is quickly scrolled into view,

Mem Usage and VM Size both go up to 1.2 GB as in the original testcase. I tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3

If suggestion #1 in comment #4 were implemented, that should make memory usage barely go up with the original testcase. If suggestion in comment #5 were implemented, that should make memory usage go up hardly at all even with the extra step 4a.

Comment 9

[Stuart Parmenter]

What you mention in comment 5 is what I'd like to see us do eventually, but I'm not sure we'll get it done for this release....

Comment 10

[Stuart Parmenter]

We're going to optimize single color images and we're throwing images away now fairly aggressively.  Our peak memory usage will be worse but our general memory use should be better.

Comment 11

[Ryuichi KUBUKI]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041017 Minefield/3.0pre ID:2008041017

I managed to make it have 9000 GDI objects. A build from 2 days ago was not like this.

Comment 12

[Martijn Wargers (dead)]

Wait and see if fixing bug 427985 fixes that for you?

Comment 13

[Alfred Kayser]

GDI issue seems to be fixed in Firefox 6.0, as it doesn't get more with loading 500 images. (probably by the layered rendering).
And the memory is released when page is not visibile in about 20 seconds in Firefox 7.0b2.

              			Memory (Private WS)   	GDI Objects
Firefox 7.0b2
with 1 image:    		84K 					96
With 500 images: 		1415K					96	(When page is visibile)
Switch to another tab:	161K               		96  (after about 15-20 seconds)

The 1200K extra memory is reported in 'about:memory' as: 1,217.81 MB -- gfx-surface-image

In Firefox 6.0:
With 500 images: 		1415K					96	(Also when page is not visibile)
After closing the page: 158K					96



So, may be this bug can also be closed now?

Comment 14

[Mike]

(In reply to Alfred Kayser from comment #13)
> So, may be this bug can also be closed now?
http://blog.mozilla.com/nnethercote/2011/08/31/memshrink-progress-week-11/comment-page-1/#comment-1544

Comment 15

[Alfred Kayser]

The decodeondraw doesn't seem to reduce memory (yet) in current nightly.
If closing of this bugs depends on that, the decodeondraw bug should linked to this one.

Comment 16

[Nicholas Nethercote [inactive]]

This is treading much the same ground as bug 683284, so I'll mark this as a dup.