extreme memory bloat on page with too many images




17 years ago
16 years ago


(Reporter: netdragon, Unassigned)


({memory-footprint, perf})

Windows XP
memory-footprint, perf

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [bae:20020130], URL)



17 years ago
********  WARNING - If your system isn't stable - DO NOT TRY THIS!!!! ********

Windows 9x, ME users DO NOT TRY THIS!!!!!!!!

The following page has only one image repeated over and over:


It loads fine - it shows what the following page should look like.

*****WARNING!!!! - BE CAREFUL ->


The memory bloats to so much that I can't even check it before end tasking
Mozilla which takes about 5 min. BTW - this crashed IE, and Explorer.

I thought about this when browsing for "wholesome" images on usenet with outlook
express and did combine and decode on about 50 images and it brought my system
to a crawl.

This is important to fix if we ever want do anything like that in MailNews.
I'm sorry to tell you that no matter how hard I try, I can't get my mozilla to
crash. 2002-01-29-09, MathML/SVG, Win32.

Comment 2

17 years ago
silly piece of math for test2:
1024x768, 24bit depth, 200 images sums up to 450 M just to decode the pictures.

Something is bloated.

Comment 3

17 years ago
From what I've heard and tried, the second page uses about 300MB of RAM
(including Netscape base mem) after all is said and done, but probably more
in-between start and finish of page load.


The problem is that if someone has less ram than is needed, their system will be
brought to a crawl. On windows 9x, ME, they would probably have to reboot. 

There needs to be some way to not have all the page loaded at once.

Comment 4

17 years ago
BTW - the repeat of images is an error on my part. The script I used to write
the pages appended the files instead of overwriting them. I meant to go up to
100 and that's it. I don't think the second set uses up more memory once the
page is loaded, though - but as axel said, in decoding it does.

Comment 5

17 years ago
Results on Win98, 400MHz PII, 128 MB physical ram:

Even though Mozilla allocated 200 MB ram for the page, it didn't freeze.  It 
slowed down my computer a little, and scrolling wasn't blazing-fast.  There 
were a few blank spots on the page near the middle and end (why?).

Displaying lots of images requires lots of memory, so we might not be able to 
do much about this problem except by limiting memory usage per window (bug 

By the way, Mozilla has no problem loading reasonably large numbers of images.  
For example, it can load all the images in http://dmoz.org/images/moz/ or in an 
average porn thumbnail gallery using the Linked Images bookmarklet at 

Comment 6

17 years ago
Confirming. This looks bad - good catch netdemon. 

Removing from blocker radar -> critical, and sending to layout for investigation.
Assignee: asa → attinasi
Severity: blocker → critical
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen

Comment 7

17 years ago
For now, limiting the mem use per window based on physical and virtual mem
available would be a good fix. In the long term, though, it would be nice if the
page could load the piece that's visible in the window by storing the size of
the images, etc and figuring out what part of the window is visible (including a
little bit to scroll with) and only load that part of the page from the disk
cache (or something like that :)

Photoshop uses a scratch disk for extremely large images. I made an image that
was a 1GB jpg of a gradient. Although it was extremely slow, it worked. It would
be nice if Mozilla could do something like that.

See also bug 100250

Comment 8

17 years ago
Pages with extremely large images, or the number of images used here would not 
be that common. Moving this out to future, leaving at critical, will review this 
during final triage.
Keywords: perf
Priority: -- → P3
Whiteboard: [bae:20020130]
Target Milestone: --- → Future

Comment 9

17 years ago
is this significantly different from my bug 51028?

Comment 10

17 years ago
I have no clue, because I was unable to test the page nor was the enough
information about exactly what the page was like. I would assume no because IE
gets nailed just as badly as Netscape does.

Comment 11

17 years ago
sorry, my university account expired, url updated. -- if you need the files, i 
have local archives of them :-)

Comment 12

17 years ago
timeless: I'd rather we do it a safe way (via ftp). I'll email you the info
about your temporary account on ftp://ftp.netdemonz.com .

Your account will expire on my 22nd birthday ( bug 69780 :)

Comment 13

17 years ago
I changed the locations of these files - 





I also changed them so they only show 100.


17 years ago
Summary: EXTREME memory bloat! System brought to crawl on page with too many images → extreme memory bloat on page with too many images

Comment 14

17 years ago
timeless, if you had problems accessing the ftp server - it should be fixed. I'm
still interested in seeing those files (in a safe manner) :-)

I removed the expiration date on the account.


A good way to fix this is to only render a portion of the page at a time when it
is extremely large. There is no reason to show the entire page at one time if it
is this large and memory can't handle it since it won't make things any faster.
There are a number of bugs that would be helped by this including - bug 49539.

Comment 15

17 years ago
A testcase: http://www.gas-turbines.com/squirt_2.htm

This page has 88 images, and the author didn't use thumbnails. He rather just
resized the images with the height and width attributes of the img tags. Some of
the images are really about the size of 1600x1200 pixels. 

When I first got on to this page, I noticed that some of the images didn't show
up on the page, so I just clicked the image space with right mouse button and
selected 'View Image'. Result: instant reboot of the computer.

After rebooting I tried it again, no crash this time, the image just didn't
load. Tried to open a new navigator tab, and then the things really got weird.
The whole interface bugged like hell, resizing the browser refreshed things a
bit but it still was really psychedelic. I tried to take a screenshot but that
didn't work either.

Ok, so I tried it again and this time kept checking the memory usage. After the
page had loaded, Mozilla took up over 200M of memory. I also noticed that if I
scrolled the page up & down a few times, the memory usage started to drop down.
After several scrollings I got it as low as 20M.

Tested with builds 2002040203 and 2002040803 on Windows 2000 with 512MB RAM.

Comment 16

17 years ago
Confirmed on build 2002052309 (Linux/X11).  Page with 141 1280x960 images, each
shrunk to 160x120 using WIDTH and HEIGHT attributes in IMG tag, requires 1GB RAM
(allocated to Mozilla while decoding, X afterwards).  Netscape 4.05 requires
only 50MB (Netscape+X11 combined) for the same page, and loads 2-3 times faster
as well.  Shouldn't Mozilla only keep the shrunk image in memory, not the full one?


17 years ago
Keywords: 4xp

Comment 17

17 years ago
there is some bug related to multiple palette creation, but i cant find it right
now ...
btw, test url is down

Comment 18

17 years ago
Sorry. The URL is down because I moved back into my house from college and I 
have to get my ports opened from the ISP to host servers. In time it will be 
back (Most likely before this bug is addressed)

That palette bug (if it is about true-color GIFs) is mine. That will help you 
find it. I am not going to actually retrieve it though since I'm not sure its 
the one you are talking about.

Comment 19

17 years ago
Any news on the testcase?
Keywords: footprint

Comment 20

17 years ago
The news is that I got business service so once I do some house-cleaning on 
the server, it will be back up.

Comment 21

17 years ago
The URLs will be different though.

Comment 22

16 years ago
Reassigning to other@layout.bugs until someone willing to take it.
Assignee: attinasi → other
Priority: P3 → --
Target Milestone: Future → ---
Priority: -- → P4
Target Milestone: --- → Future
This is the same issue as bug 51028 -- we use a lot of memory for images.  Life
is hard.

*** This bug has been marked as a duplicate of 51028 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.