Closed Bug 165860 Opened 23 years ago Closed 23 years ago

sys-con.com - 100% CPU as loading page

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 97815

People

(Reporter: primorec, Assigned: attinasi)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

offending HTML page
175.78 KB, application/octet-stream
Details
second part of the offending HTML page
136.72 KB, application/octet-stream
Details
Mozilla renders the page sooooooooooo slooooooooooooow that is more or less useless. Can I reproduce the bug ? YESSSSSSSS... any time !! STEPS to reproduce the bug ____TEST ONE_____: A) start the timer on your wrist watch B) click on http://www.sys-con.com/java/article.cfm?id=1597 C) wait for 30-45 seconds D) miracle ... the page is rendered... stop the timer E) read the timer on your wrist watch. The reading will be between 35 and 45 seconds ____TEST TWO_____: A) start the timer again B) click View-->Text Zoom-->150% C) wait 28-35 seconds D) unbeliveable... page zoom is done ... stop the timer E) the reading is between 28-35 seconds ____TEST THREE___: A) start the timer once more B) click on one of the links (read & respond...) on the same page C) 40 seconds later the page is finally rendered IMPORTANT NOTE: CPU load was always 100% during waiting period and the complete desktop (KDE) was not responsive. Mouse was fast... but click on anything did make any difference. KDE was almost dead. TEST conditions: --- REDHAT 6.2 (kernel 2.2.14-5.0) --- CPU 400MHz Pentium I --- 396MB RAM ( yes... plenty of RAM) Output of the command "free" total used free shared buffers cached Mem: 387512 375644 11868 69020 83452 139336 -/+ buffers/cache: 152856 234656 Swap: 136040 13020 123020 --- KDE 1.1.2 --- Mozilla 1.1 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 ====================================== and NOW, the sad and embarrassing fact ====================================== I have repeated ALL the test from above on the same computer on the same operational system (LINUX) running MSIE5.0 on WIN98 under VMWARE. A grown man would expect to get worse results. LINUX must work really hard to run VMWARE+WIN98+MSIE on top of other tasks. The real result was just the opposite. MSIE5.0 finished each of the tests from above in 6-9 seconds (5-8 times faster). Please, do not forget, MSIE was running under VMWARE !!!! And NO.. I am not connected to the NET with the modem. I am running the show on the DSL with the average transfer rate of 780Kbit/sec (circa 60KB/sec)
One additional detail. I've tried the same test on SOLARIS on ULTRA10 box with mozilla 1.0. Mozilla was DOG SLOOOOOOOOOW.
Attached file offending HTML page (obsolete) —
It seems that the offending site is down. Luckily I've saved the page to my local disk. Yes, mozilla is dog slow even when it renders the page from the local disk. Please unzip and untar the file and try it. WARNING: I couldn't upload the complete attachment at once, because the file is (was) bigger than 300KB. Therefore this is the part 1/2 of the file. Please download it to your system and rename it to "xaa", then download the part 2/2 and rename it to "xab". Put both files together with command cat xaa xab > slow.tar.gz gunzip slow.tar.gz tar xvf slow.tar then start mozilla and load the HTML page
Attached file offending HTML page —
It seems that the offending site is down. Luckily I've saved the page to my local disk. Yes, mozilla is dog slow even when it renders the page from the local disk. Please unzip and untar the file and try it. WARNING: I couldn't upload the complete attachment at once, because the file is (was) bigger than 300KB. Therefore this is the part 1/2 of the file. Please download it to your system and rename it to "xaa", then download the part 2/2 and rename it to "xab". Put both files together with command cat xaa xab > slow.tar.gz gunzip slow.tar.gz tar xvf slow.tar then start mozilla and load the HTML page
This is part 2/2
WARNING !!!! Please DO NOT use attachment (id=97368) !!!!!! Please USE attachment (id=97369) = xaa and attachment (id=97370) = xab Download them, rename them (xaa, xab), put them together (cat xaa xab > slow.tar.gz), unzip the resulting file (gunzip slow.tar.gz), untar it (tar xvf slow.tar), start mozilla and load the HTML file
loading the offendig page from the local disk is even slower. It takes almost 60 seconds
Opera6.0 is lightning fast. The whole page is rendered in 4-6 seconds, regardless of the source, local disk or http. Reminder: same computer and same OS.
Comment on attachment 97368 [details] offending HTML page wrong attachment
Attachment #97368 - Attachment is obsolete: true
Adjusting summary, old one was "mozilla 1.1 is dog slow (almost useless)" I'm using BuildID 2002082008 on Win2KSP2. Confirming and marking All/All as happens on Solaris, Linux and Windows. Running the URL through W3C's validator gives a whole load of incorrectly nested tags and missing start/end tags messages but in theory this should not slow mozilla down that much should it? Dropping down to major as there is no data loss/crash/hang
Assignee: asa → attinasi
Severity: critical → major
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
OS: Linux → All
QA Contact: asa → petersen
Hardware: PC → All
Summary: mozilla 1.1 is dog slow (almost useless) → sys-con.com - 100% CPU as loading page
Actually, not closing (font) tags is a big perf hit, bug 97815. I saved the page and removed all the <font> tags, that page loads in ~1 sec. *** This bug has been marked as a duplicate of 97815 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I do not see any unclosed <font> tags. They are definitely deeply nested, but AFAICT, properly closed. bug 62203 appears to be a better dupe
OS: All → Linux
Hardware: All → PC
There are 398 <font> tags and 272 </font> tags according to vim.
I am not HTML guru... but from the observation the bug 62203 is not the appropriate dupe. I've checked that bug and when I click on http://www.adventuregamer.com/ the page renders in 5-7 seconds. NOTE: right now I am downloading 5 ISO images from the net and burning one CD. So, the response time is OK. In other words, the http://www.adventuregamer.com/ triggered the bug 62203. I do not see slowness with moz 1.1 on that page. So, I think, these two bugs are different. CPU usage does not go to 100%. Same with their other test case http://www.worldofmi.com/
So best left as a dupe of bug 97815 and this happens on all platforms so setting back as such
OS: Linux → All
Hardware: PC → All
> There are 398 <font> tags and 272 </font> tags according to vim. are we looking at the same testcase? I took the testcase and removed everything but the inner (main) table. Also removed the form near the bottom. It takes ~1 minute to load. :%s/<font//g 20223 substitutions on 569 lines :%s/<\/font//g 19988 substitutions on 231 lines A bit uneven, but 140 out of 20000 doesn't seem so bad. :) The last paragraph has 111 duplicate <font> tags and properly closes all of them.
QA Contact: petersen → moied
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: