Closed Bug 178809 Opened 18 years ago Closed 15 years ago

Animated GIF causing large bloat

Categories

(Core :: 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: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.