282648 - Inefficient memory use if page contains too many pictures

Status: RESOLVED INVALID

(Core :: Graphics: ImageLib, defect)

Description

[Raymond Lai]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050121 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050121 Firefox/1.0

The page contains 130 pictures, each averaging 200KB. However, firefox hogs
140MB RAM for this page instead of about 30MB. 

Reproducible: Always

Steps to Reproduce:
1.Open firefox
2.Check firefox memory usage
3.go to http://www.hup.hu/modules.php?name=News&file=article&sid=7254
4.Check firefox memory usage

Actual Results:  
memory usage increased by 140MB

Expected Results:  
memory usage increased by 30MB

Comment 1

[Andreas]

Tested this on Trunk 17 Feb W2K.

Result was:

Loading the initial site i ended up with 230 MB of RAM allocated.
Now i minimized FF and memory went down to normal.
Maximizing FF again i had around 13 MB allocated , but as soon as i start
scrolling down the RAM usage goes up with every step scrolled down. 
Memory is not released once the picture has passed the viewing area.

Comment 2

[dolphinling]

This is a dupe, I don't know the bug number unfortunately.

-> Core: ImageLib to see if they know.

Comment 3

[WADA:World Anti-bad-Duping Agency]

Do you use extentions or themes?

If yes, test again on pure Mozilla, please.
I experienced large memory size increase in tha past, but it was due to bug of
an extention, the extention did not destroy JavaScript object when tab/window
was closed.

If problem on pure Mozilla, Real memory leak? Image only problem?

Mozilla still has problem of Bug 130157 / Bug 174604, and many bugs on virtual
memory related problem are DUPed by them.
And mainly by this problem, many users complaint on Mozilla family in bugs such
as Bug 76831.
And another bug reported killing of Mozilla process by OS(*nix,Linux...) due to
virtual memory size limitaion of application.

I think this kind of problem Mozilla still has is "inefficient use of virutual
memory" instead of "memory leak".
For example,
 - Assume virtual memory is managed by 64KB block.
 - Even if only 1 byte is used in 64KB block, whole 64KB block is needed
   as virtual memory.
 - Even if resource(such as javaScript object) is destroyed, whole virtual
   memory used/obtained on object creation is not always freed.
   At least management area or control block area is required
   even after successuful deletion of object.
 - And if the 1 byte is located at mid of 64KB block,
   request for continuous area more than 32KB can't use this block,
   then additional 64KB block is obtained.
This kind of problem is not called "memory leak" usually.
This kind of problem is usually avoided by process like
 (1) Merge adjacent free memory ares to single continous free area.
 (2) Rearrangement of control blocks area such as small area
     in almost free 64KB block.
 (3) Re-use of free block as many time as possible.
 (4) Free(get it back to OS) free 64KB block or bunch of 64KB blocks
     if possible (often not freeed for performance reason). 

Question again.
Real memory leak?
Image only problem?
Isn't it DUP of Bug 130157 or Bug 174604 (not imagelib problem) ?

If your case is similar problem to Bug 130157, I think your case is very good
test case, because huge virtual memory increase can easily be observed.
Can you clarify what is happening?
(memory cache size increase, virtul memory size change on window/tab open/close
etc.)

Comment 4

[Boris Zbarsky [:bzbarsky]]

> each averaging 200KB. 

That's compressed.  We store the images in memory cache as uncompressed bitmaps.

Doesn't sound like there's a memory leak here, if leaving the page releases the
memory.  Does it?

Comment 5

[Raymond Lai]

Sorry, I was having my midterm tests this week. 

WADA, thanks for correcting me. It's indeed not a memory leak. After I closed
the page, the memory use fell back to the initial amount. 

Boris, thanks for clarifying the defference between the pixmaps and the JPEGs.
In general, how big is an uncompressed pixmap for a 200K JPEG?

Andreas, I agree with you that firefox should release the pixmaps at some point. 

I think it's not efficient to allocate and render the pixmaps all at once. This
will keep users waiting too long and overuse unneccessarily large amount of
memory. I think it should adopt the idea of ondemand rendering as in the text
editors. We could fetch all the images in JPEG forms and render the current
screen-viewable page and a few pages before and after the current page. As the
user scrolls the page, we can destroy the oldest pages, and render the next few
new pages. In short, we can just keep framebuffer just a few times of the
screen-viewable framebuffer, instead of hundreds times of the it. I believe the
ondemand rendering will make firefox more reponsive and consume way less system
resources while rendering huge pages.

Comment 6

[Raymond Lai]

updated summary

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
No. It's mainly Web page design problem.
You said "The page contains 130 pictures, each averaging 200KB" in commant #0.
 (200KB is probably compressed JPEG file size.)
Placing many large image files in a Web page can not be said good behaviour in
Web page design.
If many JPEG files in a page are really required, thumbnail file of really
smaller size should be used instead of <IMG SRC=large-JPEG-file width=small size
height=small size>.
Please note that Web page(a URL) in a tab is a "page", is not whole document in
Layouting software or Word processsor.
 Document <-> Window of Browser(=Web site)
 Page     <-> Tab of Browser(Web page in a Web site)
              (Difference: multiple page's data are kept for Back/Forward)
"opening new Web page in new tab then close old tab" corresponds to page switch
in QuarkXpress or Pagemaker.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> how big is an uncompressed pixmap for a 200K JPEG?

Depends on how well the original data compresses.  In general, a 100px by 100px
jpeg will take up 240KB uncompressed (so a 600px by 800px one would be 10MB or so).

> Andreas, I agree with you that firefox should release the pixmaps at some
> point. 

We release the pixmaps once they are no longer needed (eg once you leave the
page), or when the memory cache is flushed by either the memory pressure
observer or some other mechanism.

> I think it's not efficient to allocate and render the pixmaps all at once.

The uncompressed image data is needed for more than just rendering (eg you
actually need to get at some of it to lay the page out at all; if nothing else,
you need the image size).

Also, Mozilla stores the images on the graphics card as much as it can (for
which they need to be in ready-to-render form).  With the exception of
particularly pathological cases like this one, this is a huge win, since the
image data is not even in RAM at all.

All this has been discussed to death in previous bugs and newsgroup discussions...

Comment 9

[Raymond Lai]

Boris, thanks for the explanations. I will close the bug.