From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 BuildID: 2002053012 I can't show you this page, unfortunately, because it contains sensitive data. I'll give you my best description. The page is just under a megabyte in size: all text. It's a table with 4000 rows, 1400 textareas and 1400 option boxes. On loading it takes about a minute to process, takes up all my memory (512MB) and causes general system instability afterwards. The obvious solution is not to go to pages this large. That's not an option. I have the same problem with the commercial release of Netscape. Internet Exploder and Opera process the page in about ten seconds. Hope that helps. I love Mozilla. Reproducible: Always Steps to Reproduce: 1. Go to page. 2. Watch. Actual Results: Page loaded after about a minute of cranking. Expected Results: Loaded page more quickly. Sorry I can't give you a public page to try this in. Make a table with a gajillion rows where the whole damned thing is a form and you'll see it.
Over to HTML Tables.
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → amar
nope, not a table problem. I tried two test html files, one with 60 or so forms, each containing one checkbox and one textarea, and one with a table with the same number of rows. The first test renders much slower than the second. So I suspect it's a problem of creating control objects effectively. a solution could be setting the max string length for the textarea.
reporter (or someone else): can you reproduce this problem with a recent build of mozilla? if so, could someone attach a test file which shows the disproportionate slowness? if not, please resolve this bug as WORKSFORME. thanks.
I can confirm this bug is still with us. Just tested it again with Mozilla 1.1b Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 Had the same experience. A competitor's browser loaded the page in 15 seconds. I stopped waiting for mozilla to render the page after 8 minutes.
I taught myself perl and whipped up a mock-up of the page without all the sensitive information that the original contains. I've made two versions of the page: one with 20 three-row records and one with 2000. If you want to see what it looks like, I'd recommend the 20 record version, as it loads in Mozilla with no problem. You can see for yourself what the problem looks like itself with the 2000 record version. http://www.zillmann.org/cgi-bin/bug152385-20.pl http://www.zillmann.org/cgi-bin/bug152385-2000.pl And once again, you all rock for looking at this. Mozilla rules. And I'm sorry if I'm doing this wrong.
Reply to #5 I can confirm the Problem with http://www.zillmann.org/cgi-bin/bug152385-2000.pl and Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020818 Load-speed is very slow (only more or less 5% of my possible ISDN-speed) System-stability gets bad I watched that for 20 seconds and then I stopped because I was afraid that my system might crash IE6 loads rather quick (app. 15 seconds), but also has problems with te page: Some Input-Panes (containing "first thing") do not scroll correctly with the rest of the page, if I use the scroll-knob on the scrollbar. The IE6- Problem might have been caused by having loaded the page with mozilla before, I will test again after a restart.
Reply to #6 I'm glad the examples are helpful. I have witnessed the same scrolling problem you reported with IE6 (option boxes not displaying correctly during scrolling) only on a Windows Me box up to this point. I've seen Opera 6.04 do the same thing. I've never witnessed it in Windows 2000 with any browser. I don't know how the operating system might play in to this, but I felt it worth mentioning. And thanks again for helping to address this issue.
I decided to set this bug "new". May be the problems are also caused by mistakes in the html-code, but there should not be caused hangriscs or similar problems by corrupted code. I am not shure whether the problem are "tables", so component should be set back to "Browser general"
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've setup a different test case. This loads fine with Opera 6.05 and IE 5.5 but with Mozilla 1.1 build 20020824 loading this page takes at least 10 times longer and eats up CPU time much more than the other browsers. I'm running W2k. Testcase is here: <http://kotisivu.mtv3.fi/jjjj--l/big_table.html>.
I made some measurements with W2000 task manager. I loaded the big_table.html from comment #9 locally to the hard disk. Then I started the web browser, recorded used CPU Time, opened the file from local disk and waited for the browser to completely load the page and then recorded the used CPU Time again. Here are the results: W2000 SP2, IBM ThinkPad 600X (450 MHz PIII, 256 MB) Start End Used seconds Mozilla 0:00:34 0:01:59 85 6 times more than IE 5.5! 2002090604 Opera 6.05 0:00:03 0:00:18 15 IE 5.5 0:00:01 0:00:15 14
Once bug 54542 is fixed this will also be considerably faster.
Depends on: 54542
OS: Windows 2000 → All
Hardware: PC → All
this is probably a dupe of bug 148636. each form control (at least textboxes) get 43 EventListeners (among other things). Any perf hit here is probably overshadowed by swapping due to memory usage. A table this small (2000 or even 4000 rows) should not be a perf or memory problem. See bug 148338
Probably also related to bug 94587.
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
http://us2.php.net/get/php_manual_en.html.gz/from/a/mirror is another one of those pages. It's over 1 mb. It does survive the long load times though. But if you try viewing the source, everything goes unresponsive.
(In reply to comment #12) > this is probably a dupe of bug 148636. each form control (at least textboxes) > get 43 EventListeners (among other things). Any perf hit here is probably > overshadowed by swapping due to memory usage. > If I had found bug 148636 before I created this one, I wouldn't have submitted this bug. I don't know if it's really the same issue, but it sure sounds like it to me. If a reporter's opinion is worth anything, I move that this bug be resolved as a dupe.
I'm convinced it's a dupe, so I'm possibly stepping out of line by trying to officially classify it as a dupe. *** This bug has been marked as a duplicate of 148636 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.