Closed Bug 178809 Opened 22 years ago Closed 20 years ago

Animated GIF causing large bloat

Categories

(Core :: Graphics: ImageLib, defect, P3)

x86
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 126445

People

(Reporter: craig, Assigned: jdunn)

References

()

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021014 Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021014 On some pages, such as this one, Mozilla uses amazingly large amounts of RAM. Reproducible: Always Steps to Reproduce: 1. Check free memory in Windows 2. Go to URL 3. Check free memory again Actual Results: Mozilla's gobbled about 34MB RAM! Expected Results: Well, Netscape 4.80 uses up about 1.2MB on the same page. I have no idea which specific bug this should be attributed to or what specific area is broken, but this really cripples the performance of Mozilla at times. If you happen to be close to running out of real RAM, the disk thrashes like crazy with all the swapping.
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126 It seems to be about 35MB now!
Similar result under: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130
OS: Windows 95 → All
Confirming. The page requires ~32 Megs of Ram to load. Nav. 4.79 barely changes in the amount of RAM used.
Assignee: asa → saari
Severity: major → normal
Status: UNCONFIRMED → NEW
Component: Browser-General → DOM Events
Ever confirmed: true
Priority: -- → P3
QA Contact: asa → vladimire
taking... saari, I'm guessing that you are very busy and will appreciate the help! Please let me know if I am stepping on your toes! :-) ccing some other Mozilla hackers interested in keeping footprint down...
Assignee: saari → nisheeth
Craig, can you post some other urls where you've seen this happen? Thanks!
Status: NEW → ASSIGNED
This seems kind of vague - I mean of course mozilla takes up some huge amount of memory. that's the general footprint tracking bug I guess, and we can always use help on it. If we want to talk about leaks, I guess you could start with the general leak bug that seth just opened. Is this really specific to DOM Events? Put simply, this isn't going to get fixed until we can find some specific URLs that exacerbate the problem. Craig?
I haven't spent much time on this except eyeballing task manager numbers. Here's what I found. The good thing is that we reclaim almost all the memory when we leave the page. So, its definitely lower priority than leak fixes. The bad thing is that IE takes up an additional 13MB RAM as opposed to Mozilla's 34MB to load this page. I wonder what this site and Mozilla are doing that causes such a large difference in memory use? I am currently working on a few security bugs. Will look at the leak bug (I'm guessing you are talking about bug 195163) and then this bug later this week...
I experience the same problem with Mozilla 1.7 RC2. It just seems that page after page, Mozilla grows fat. My opinion is that, except adding the page to the history list, when leaving a page to return to an old one, the amount of memory should dramatically change. It is not the case. I tested the page http://homepage.ntlworld.com/wilf.james/cons2002.htm and memory jumped from 25 to 55 Mo of RAM. The more you browse, the less you will ,) For your information, the same happens with Firefox 0.8. Woh: 55 Mo to display a mere page, is there any junks loaded secretly with this page???
jean-cristophe, please check that what you're seeing is not a problem with the libc memory allocator (bug 130157) as opposed to Mazilla.
when i go to the url, the memory usage jumps from 27mb to 60mb. i click "back" and the memory immediately returns to 27mb. i'm using firefox0.8 on win2k.
First of all, I am not using Mozilla 1.7 RC2 under Linux, but under XP, or the bug you refer to seems to happen under Linux. Then, I tried with other browsers, which all jump 20 Mo bigger after displaying the page indicated, so I think this page is greedy :) To bounce on mstrumyla@accordant.net 2004-05-18 14:38 PDT remark, when going back to the previous page, Mozilla also comes back to a normal level of memory usage, just like Firefox 0.8 I just wonder how a mere HTML page can require 25 Mo to display!!!??? Note that the same amount of resource is needed for IE 6...
So comment 7, over a year ago, says Mozilla then bloated by more than twice the amount of memory that IE (unknown version) bloated by when loading the page. Comment 11 today says Mozilla and IE6 bloat by the same amount. Progress, can anyone else confirm? Linux and other Unixes may just suffer from failure to return unused malloc heap to the OS. Is this bug useful for more than chinwagging? /be
(In reply to comment #12) > So comment 7, over a year ago, says Mozilla then bloated by more than twice the > amount of memory that IE (unknown version) bloated by when loading the page. > Comment 11 today says Mozilla and IE6 bloat by the same amount. Progress, can > anyone else confirm? If IE has become even worse than it was, that doesn't count as "progress" for Mozilla. Mozilla still uses about 20 times as much RAM when rendering that page as Netscape 4.x. The more relevant comment than any IE comparison is the previous sentence: "I just wonder how a mere HTML page can require 25 Mo to display!!!???" Also, looking at it under Win95, the page gets to 99% rendered without using any significant resources at all. Suddenly, as it completes the page, Mozilla grabs an enormous chunk of RAM. Makes me wonder whether it's needed, or just a programming error.
We have tools that would tell, spacetrace mainly, although selective trace-malloc use could do the trick. If this bug stands for the sudden surge at the end of page-load on Win95 (!! -- I thought we dropped support long ago), great. But its OS setting is "All", and it is full of vague complaints, including probable complaints about Unix/Linux malloc not returning heap to the OS. The signal-to-noise ratio is low, and the assignee is not hacking on Mozilla now (much or at all -- he's at Stanford doing a master's degree). I'll shut up so I don't degrade the S/N further, but I think this bug is in need of good ownership soon, or it will be marked INVALID. Vague bugs, like vague law, are bad bugs. /be
(In reply to comment #14) > If this bug stands for the sudden surge at the end of page-load on Win95 (!! -- > I thought we dropped support long ago), great. Oops. Meant Win9x. I don't think this bug is vague at all. Given a specific simple HTML page, Mozilla uses up astronomical amounts of RAM, both under Win9x and Linux. I don't see how much less vague a bug report can be, without delving into source code. I agree with you about the noise. Conjecture here is useless. It's a nasty bug. Mozilla on some pages uses up enormous amounts of RAM, crippling systems which don't have enormous amounts of RAM to spare. Unless someone works out what exactly Mozilla is grabbing the enormous slab of RAM for, further posting to this bug is not useful.
(In reply to comment #12) > So comment 7, over a year ago, says Mozilla then bloated by more than twice the > amount of memory that IE (unknown version) bloated by when loading the page. > Comment 11 today says Mozilla and IE6 bloat by the same amount. Progress, can > anyone else confirm? The comment 7 is still valid. I tested using win2k. ie6.0sp1 before the url was loaded - 27mb; the url loaded - 60mb; clicked "back" - 27mb firefox0.8 before the url was loaded - 10mb; the url loaded - 22mb; clicked "back" - 10mb
switched firefox with ie :) The comment 7 is still valid. I tested using win2k. firefox0.8 before the url was loaded - 27mb; the url loaded - 60mb; clicked "back" - 27mb ie6.0sp1 before the url was loaded - 10mb; the url loaded - 22mb; clicked "back" - 10mb
well, aside from this guy being a bit of a convention nut, I don't see anything unusual about the page at first glance - I don't even see any JavaScript running here. And sure enough, it spikes right as the page finished loading. Maybe its a bad image? Reporters, and people on the CC: If anyone wants this bug fixed, they're going to have to break down the source of the problem here's a few suggestions: 1) load this file locally, i.e. not over the network. When does it spike? 2) cut and paste sections of this page into a blank HTML page and load that. Is there a specific part of the page that makes the spike happen? 3) view some of the images. Are they causing the spike? it does NO good to post in a bug "me too!" and not offer any additional help in narrowing down the cause of the bug.
Summary: Mozilla using enormous amounts of RAM → Mozilla bloating on this url
(In reply to comment #18) > Maybe its a bad image? yep, it's one animated image - jedimov.gif. its size is 94kb. its size in mozilla's memory cache is ~31mb. i found out about it by looking at about:cache?device=memory
Attached image jedimov.gif
i'm attaching the animated gif.
nice! Now we can assign it to a proper owner!
Assignee: nisheeth_mozilla → jdunn
Status: ASSIGNED → NEW
Component: DOM: Events → ImageLib
QA Contact: vladimire
it could also be a cache bug
Summary: Mozilla bloating on this url → Animated GIF causing large bloat
That image is an animated GIF with 28 frames, all of size 1057x355. Since we store all images internally as 24-bit RGB and have an extra composite frame, we end up using about 31MB for the image (plus whatever overhead a platform's gfx might have). I'd like to change over to storing the animation frames as indexed data, which would drop this down to about a third of the current value. They're likely be some tradeoff in speed doing this, though.
For the many people who have Mozilla set to run through animations once, or not at all, would it be possible to simply store only one frame and discard the rest?
re comment 12, brendan, yeah bug 51028 has some analysis of various versions of ie/mozilla. the comments are correct, i believe the calculations ascribe the jump to alpha bits in ie6. i'm not sure if this bug is anything but noise and am sorry to add to it.
(In reply to comment #25) > re comment 12, brendan, yeah bug 51028 has some analysis of various versions > of ie/mozilla. the comments are correct, i believe the calculations ascribe > the jump to alpha bits in ie6. Why should we care purely what IE does? If IE were the baseline for what's acceptable for a browser, Mozilla would not need to exist at all. > i'm not sure if this bug is anything but noise and am > sorry to add to it. Using 30+MB for a single image is bloat and should be fixed. That NS4.8 only used 1/20 the RAM simply proves that such bloat is totally unnecessary but, beyond that, comparisons are unimportant. The bloat reduces Mozilla's usability a lot. The only noise I see here is comment #25.
*** Bug 256858 has been marked as a duplicate of this bug. ***
I think this could be marked as a dup of bug 126445
*** This bug has been marked as a duplicate of 126445 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: