Closed Bug 122581 Opened 23 years ago Closed 22 years ago

extreme memory bloat on page with too many images

Categories

(Core :: Layout, defect, P4)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 51028
Milestone:
Future

People

(Reporter: netdragon, Unassigned)

References

(
URL
)

Details

(Keywords: memory-footprint, perf, Whiteboard: [bae:20020130])

******** 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: http://mozilla.netdemonz.com/src/patchandtest/too%20many%20images/test1.html It loads fine - it shows what the following page should look like. *****WARNING!!!! - BE CAREFUL -> http://mozilla.netdemonz.com/src/patchandtest/too%20many%20images/test2.html 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.
silly piece of math for test2: 1024x768, 24bit depth, 200 images sums up to 450 M just to decode the pictures. Something is bloated.
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. Source: http://mozilla.netdemonz.com/src/patchandtest/too%20many%20images/test1.html.txt http://mozilla.netdemonz.com/src/patchandtest/too%20many%20images/test2.html.txt 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.
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.
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 70821). 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 http://www.squarefree.com/bookmarklets/pagelinks.html#linked_images.
Confirming. This looks bad - good catch netdemon. Removing from blocker radar -> critical, and sending to layout for investigation.
Assignee: asa → attinasi
Severity: blocker → critical
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen
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
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
is this significantly different from my bug 51028?
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.
sorry, my university account expired, url updated. -- if you need the files, i have local archives of them :-)
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 :)
I changed the locations of these files - http://www.netdemonz.com/src/projects/patchandtest/bug%20122581%20-%20too% 20many%20images/test1.html http://www.netdemonz.com/src/projects/patchandtest/bug%20122581%20-%20too% 20many%20images/test2.html http://www.netdemonz.com/src/projects/patchandtest/bug%20122581%20-%20too% 20many%20images/test1.html.txt http://www.netdemonz.com/src/projects/patchandtest/bug%20122581%20-%20too% 20many%20images/test2.html.txt I also changed them so they only show 100.
Summary: EXTREME memory bloat! System brought to crawl on page with too many images → extreme memory bloat on page with too many images
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.
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.
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?
Keywords: 4xp
there is some bug related to multiple palette creation, but i cant find it right now ... btw, test url is down
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.
Any news on the testcase?
Keywords: footprint
The news is that I got business service so once I do some house-cleaning on the server, it will be back up.
The URLs will be different though.
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 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.