Closed Bug 238448 Opened 22 years ago Closed 16 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: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.