Closed Bug 238448 Opened 20 years ago Closed 15 years ago

Extremely high CPU and RAM usage on this page

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: camecek, Unassigned)

References

(
URL
)

Details

(Keywords: perf) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040323 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040323 Firefox/0.8.0+

When visiting the site
http://utklan.kvalitne.cz/chat/gbook.php?pos=120%E2%8C%A9=cz, Firefox memory
usage increases drastically upto 200MB.

Using WinXP Pro on Athlon XP 2400+ with 512MB RAM.

Reproducible: Always
Steps to Reproduce:
1. Visit the page
2. Watch memory usage increase as the page loads

Actual Results:  
Firefox subsequently freezes and memory usage is over 200MB.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040323
Firefox/0.8.0+

Once the file finally loaded the Mem usage numbers remained constant and the CPU
usage was 0%. My mem usage peaked at about 113 MB with just the URL given in
this bug and this page open. I was able to scroll through the page with out any
crashes. Note: this page is about 9.33 MB of html tables.
Not confirmed on Linux.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040322 Firefox/0.8.0+
(daihard: XFT+GTK2; opt. for P4/SSE-2)

Loading this page did not cause any dramatic jumps in memory usage, nor any
massive CPU utilization. Fx memory usage was already quite high, but it did not
increase appreciably.
Summary: Extremely high CPU and RAM usage on that page → Extremely high CPU and RAM usage on this page
Using scragz's G7 SSE2 build, my memory usage goes up to and stays at around 
120MB.  Firefox was pretty unresponsive while the page was loading but once it 
was done it acted fine and its CPU usage was normal.
Sorry, forgot to mention that I am using Windows 2000 SP4.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040323
Firefox/0.8.0+ (MozJF)

(I happened to be in Windows for once...)

Loading the page, I saw a massive jump in process size from 35MB up to nearly
82MB! Closing the tab promptly deleted 40MB of that, leaving Firefox, with five
tabs open, around 40MB.

Ergo, this bug may only appear on Windows XP/XP SP1 (which is what I'm using).
It also happen on my Win95 machine.
FireFox eats up *80Mb+ RAM when that site is being loaded.
(256MB machine, 105mb free before that page was being loaded.)
*(I had to close the browser because free memory was gone down to less than 20MB
before the page was fully loaded, so the exect amount of memory needed to fully
load that page is not known.)
NT5.0 + Opera 7.23 and 7.5 couldn't deal with the massive load,Mem usage 200+Mb
and CPUload 80-100% , before crash. Only IE seems to survive fairly well.Bad
html/excessive pagesize both to blame. Would there be a fix for this (rubbish) ? 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040320 Firefox/0.8

I have a similar problem with a 3MB big page containing only a table, but it is
correct HTML code. Memory and cpu usage increase dramatically, although Firefox
does not crash and frees the memory after closing the site.
For me it looks like table rendering under WinXP is very memory intensive and
slow, as it isn't confirmed under linux.
http://moinman.kiffer.at/Unicode.html
Sorry link doesn't work. The page gets alwasy deleted by my webspace provider.
Is this really a Mozilla Firefox bug only? If not, then the product should be
changed
(In reply to comment #10)
> Is this really a Mozilla Firefox bug only? If not, then the product should be
> changed
With Mozilla 1.7b same results, so it's not a Firefox specific bug.
My original testcase can be found here:
http://web2.ipx10555.ipxserver.de/firefox/Unicode.html (thx to DownAndUp)
A halved version of my test file can be found here:
http://moinman.kiffer.at/Unicode-Half.html
not sure this is the same bug but a similar occurence on this link
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/

well that page loads fine with Netscape7.1/ Mox1.4 .... however FireFox takes a
loooooooong time to render it and just conks out ....there seems to be a
discrepancy in the way FF and Moz suite handles the layout... i fiddled around
with the nglayout pref trying out all sorts of settings no difference....
Netscape 7.1 rendered correctly & pretty quick while FF lagged which leads me to
believe FireFox may need some rendering tweaking, Unless it is even stricter
(compliant standards) than Mozilla Suite/Netscape. I Have noticed other pages
like this before but this one is Very very Noticable

BTW i checked the cache and both programs downloaded the page (about 270KB) in
the same time again leading me to believe that the rendering is the issue....
Much more info can be found in this mozillazine thread
http://forums.mozillazine.org/viewtopic.php?t=65824

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Flags: blocking0.9?
Flags: blocking0.9? → blocking0.9+
(In reply to <a href="#c8">#8</a> and <a href="#c11">#11</a>)

> With Mozilla 1.7b same results, so it's not a Firefox specific bug.
> My original testcase can be found here:
> http://web2.ipx10555.ipxserver.de/firefox/Unicode.html (thx to DownAndUp)

Same problem here on Linux. Rendering time with Firefox is about ten times as
long as with Konqueror, both loading that file from local disk.
Still not confirmed with Linux.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040408 Firefox/0.8.0+
(daihard: XFT+GTK2; opt. for P4/SSE-2)

Memory usage hardly changed at all, and there was no runaway processor
utilization. So this is definitely not an issue on Linux (at least with kernel
2.6.0).
I can't seem to reproduce this with Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7b) Gecko/20040410 Firefox/0.8.0+
Windows xp ver. 5.1 build 2600.2096 sp2 (official sp2 beta tester)
I tried both 
http://utklan.kvalitne.cz/chat/gbook.php?pos=120%E2%8C%A9=cz
and
http://web2.ipx10555.ipxserver.de/firefox/Unicode.html
Memory load never got higher than 25,100KB and cpu load fluctuates from 8% to 15% 
even if I open both pages at once. Again, sorry, I can't reproduce this bug.



(In reply to comment #15)
I tried it with the same setup and still get the high memory and cpu usage.
(new folder and new profile)
Are you using the standard nighly Gecko/20040410 Firefox/0.8.0+ or any optimized
build - installer or zip?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040417
Firefox/0.8.0+

http://web2.ipx10555.ipxserver.de/firefox/Unicode.html

took several hours to render, and top reported these figures,
I suspect that the relevant one is RSIZE, at well over 120 MB

4254 firefox-bi  81.3% 50:04.30  10   185  1208   133M  28.8M   128M   818M


Could we dupe this to bug 61684, bug 67756, bug 97927, bug 99943, or bug 148338
all deal with huge files with lots of tables.
You do realize that setting a flag to blocking0.9+ is something only Firefox
coders and people "in the know" should do?  You can nominate, but it's up to
them to actually decide whether the bug is that important or not.
Flags: blocking0.9+ → blocking0.9?
speaking of "in the know", huge HTML tables do cause problems, not sure what 
the correct dupe is, moving to appropriate component.

This isn't going to block FF 0.9, if for no other reason than the rarity of 
megabytes of table code in a single document.
Assignee: firefox → nobody
Component: General → Layout: Tables
Flags: blocking0.9?
Product: Firefox → Browser
QA Contact: core.layout.tables
Version: unspecified → Trunk
The performance should change after the checkin on 2004-04-12 23:21. Does
anybody who has seen this before see a improvement in the nightlies starting
from 2004-04-13?
(In reply to comment #16)
it's the ofiicial nighly Gecko/20040410 Firefox/0.8.0+ installer build
Keywords: perf
Blocks: 203448
Has there been an improvement with recent builds?
(In reply to comment #23)
> Has there been an improvement with recent builds?

I see perhaps a slight improvement regarding the rendering speed but otherwise
the issue is still there and it is very frustrating. At my school they started
using large tables for displaying some web content and I have to use IE to view
these :(
I'm using Windows XP on an Athlon64 3000+ 1024MB RAM. Even after the page has
only partially downloaded (a few MB), moving the mouse around on the page causes
100% CPU usage.
Bug is still there in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060512 Firefox/1.5.0.4 ID:2006051205

it is getting up to 100 Mbytes of RAM on my computer and hangs with 100% cpu usage on that page

the url is wfm. Is this still a problem?
Berd, what did you test with?
For me it took > 30 sec to render, and UI was froze during the period. But I don't think it used excessive memory.  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091017 Minefield/3.7a1pre (.NET CLR 3.5.30729)
several of the testcase URLs no longer work and original URL is not found today.
opting for WFM per Bernd's comment 27
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.