39573 - [CBX]Mozilla takes 10 minutes to render a (large) table with form elements.

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[alla]

The above url is an example of the UI of a firewall rule editor. It takes 10
minutes to render on my Linux PIII 500 MHz machine, during which all mozilla
windows freeze. When the page has loaded you can scroll it pretty fast though.

NS 4.x loads the page quite quickly.

I'm using the 2000-05-16-08-M16 nightly build.

Comment 1

[rods (gone)]

I doubt that this is specifically a form control bug. Other tests need to be 
made. After 3 minutes on my Celeron 500mhz 128Meg (WinNT) home machine it had 
consumed 40Megs of memory (then I killed it). After looking at the source the 
only out of the ordinary thing I see is the table cells have valign.

Comment 2

[rods (gone)]

Well, the table with all the form controls is inside another table, that is like 
death. I stripped it down to have just the one big table and that seemed to take 
about two minutes to load and was about to display when it died (I am not sure 
why).

Comment 3

[rods (gone)]

Attachment: no outer table in example

Comment 4

[rods (gone)]

I crashes in nsWindow::CreateWindow and then crashes MSDEV

Comment 5

[alla]

Well, my nightly build managed to render the "no outer table" attachment.
But during layout i got a lot of:
Warning - table cell content max element height 345 greater than desired height
330
and it took a while:
Document: Done (1516.378 secs)
25 minutes!!! On a PIII 500MHz! And all windows froze during rendering.

If works fairly well when the page has rendered though. I wouldn't call it fast,
but it's usable.

Comment 6

[Jeremy M. Dolan]

Both the attachment and the URL crash todays *win32* build.

Both die at same module/address:
MOZILLA caused an invalid page fault in module GKWIDGET.DLL at 0177:60ad6446.

Comment 7

[Jeremy M. Dolan]

Interesting to note that even IE5 doesn't like this page. It smears it to the 
point of being completly unreadable. Saving the file locally and opening it via 
file:/// also crashes on win98 today, it gets the progress bar to 99% then 
dies. Is this critical/crash?

Comment 8

[buster]

pumping up the volume, since folks say this is crashing.

Comment 9

[buster]

proposing as nsbeta2 since it's a crasher

Comment 10

[rods (gone)]

This isn't critical for nsbeta2 because most browsers have an issue with this 
page. And there are hardly any pages out on the net with 3000 comboboboxes.

Comment 11

[buster]

Rod and I talked, and this sure looks like a dup of 39544.  I agree with 
rod's comment here and eric krock's comment in that bug that this problem is not 
high priority for nsbeta2.

Comment 12

[rods (gone)]

This bug has been marked "future" because at this time it has been determined 
that it is not absolutely critical for RTM (Release To Manufacturing). If the 
reporter and anyone else believe it is necessary to fix this before shipping 
Seamonkey 1.0, please describe your issue in the bug. 

Comment 13

[alla]

Well, It is pretty important to us. If this is not fixed before release our
firewall product will become unusable with Netscape 6.

Anyway. If i get some free time I'll do some profiling and see if there is some
simple fix.

Comment 14

[rods (gone)]

We have a solution, we just don't have the time to put it in. See Bug 39573. 
Maybe you could take another look at the page itself and see if there is some 
way to break it up or reorganize it so it is faster on all browsers.

Comment 15

[Jeremy M. Dolan]

See also: bug 39573 and bug 39573.

Comment 16

[Andreas Otte]

I have a page with some tables with many tablecells. This page is produced by
webalizer, a tool to analyze httpd logs. It takes some time (3 minutes) to
render the page on my linux debug build with a PII 400, mozilla nearly freezes.
The progressbar is very slow, lots of Warning - table cell content max element
height 225 greater than desired height 218 messages. See 
http://www.begriffslogik.de/wwwstats2/usage_200005.html as an example.

I think this is a nasty performance problem, the milestone should be something
else then "Future".

Comment 17

[buster]

Andreas Otte: I don't think the page you mention has anything to do with the 
problem reported in this bug.  This bug is about pages with hundreds of dropdown 
comboboxes.  I don't think the page you mention shares that trait.  You should 
submit a separate performance bug against the layout component.  Thanks!

Comment 18

[alla]

Ok. I've looked a bit at this. I find it hard to believe that the "resource"
problem described in bug 39544 is the cause of this.

First of all there is no "out of resources" in X, so this shouldn't happen in
Linux.

Second, I've done some measurments of cut down versions of the "no outer table"
page. Here is the results with the 2000-06-02 nightly build:
5 rows -> 2.2 seconds
10 rows -> 3.7 seconds
20 rows -> 10.4 seconds
43 rows -> 40 seconds
86 rows -> 173 seconds
172 rows (original) -> i didn't bother, but i'll guess about 692 seconds.

See the pattern? The *real* problem is that some part of layout or parsing seems
to use an algorithm that is O(n^2). 

I've seen bug reports showing that javascript DOM appends exhibit linear
performance (instead of constant), which could be related to this bug (ie.
linear append for each row means O(n^2) to add n rows).

On the subject of breaking up the page. I've discussed it with the product
people, it's difficult, but we'll probably do it anyway. The problem doesn't go
away then either though, i.e. 10 seconds for 20 lines of rules is still to slow.

Btw. Why do every see bug xxx in this bug reference 39573 (this bug)?

Comment 19

[buster]

I'll bet it has to do with pre-building all those drop-down lists.  I wouldn't 
be surprised if core block layout was doing all kinds of unnecessary work for 
those lists.  nsBlockFrame::RenumberList() comes to mind.  We should be able to 
mark blocks that have restricted content, so we don't do extra work that's 
required for general blocks.  Or, we could build a subclass that shuts off some 
default behaviors that are not needed.  That might require factoring the code a 
bit more.

Comment 20

[alla]

This should be fairly easy to spot in a profiler. Unfortunately gprof doesn't
work with Mozilla, so i can't test it. I thought the profiler worked on Windows?
It would be nice with some hard facts on where the time is spent.

Comment 21

[rods (gone)]

The problem is, we layout all the dropdowns to get their appropriate size so the 
combobox itself knows what size to be. I have some code in it's early stages 
that can measure the widths of the dropdown and doesn't have to lay them out 
until it is time to pop them down (the easy part). This means we could do lazy 
instantiation of the dropdown when the user clicks on it the first time (the 
hard part and time consuming part of fixing this bug).

Comment 22

[redin]

> The problem is, we layout all the dropdowns to get their appropriate size so
the combobox itself knows what size to be. 

Should it not take O(n) with n rows of identical comboboxes if that is the main
problem?
It must be something more that is wrong if it takes O(n^2).

Comment 23

[Andreas Franke (gone)]

Here is a typical stack trace, obtained by interrupting mozilla while loading 
the "no outer table" example (PC/Linux debug build from 7/21):

#0  __select () from /lib/libc.so.6
#1  __DTOR_END__ ()
#2  _XRead ()
#3  _XReply ()
#4  XGetWindowAttributes ()
#5  gdk_window_get_events ()
#6  nsWindow::CreateNative ()
#7  nsWidget::CreateWidget ()
#8  nsWidget::Create ()
#9  nsView::CreateWidget ()
#10 nsListControlFrame::CreateScrollingViewWidget ()
#11 nsScrollFrame::CreateScrollingView ()
#12 nsScrollFrame::Init ()
#13 nsListControlFrame::Init ()
#14 nsCSSFrameConstructor::InitAndRestoreFrame ()
#15 nsCSSFrameConstructor::InitializeSelectFrame ()
#16 nsCSSFrameConstructor::ConstructSelectFrame ()
#17 nsCSSFrameConstructor::ConstructFrameByTag ()
#18 nsCSSFrameConstructor::ConstructFrameInternal ()
#19 nsCSSFrameConstructor::ConstructFrame ()
#20 nsCSSFrameConstructor::ProcessChildren ()
#21 nsCSSFrameConstructor::ConstructTableCellFrame ()
#22 nsCSSFrameConstructor::TableProcessChild ()
#23 nsCSSFrameConstructor::TableProcessChildren ()
#24 nsCSSFrameConstructor::ConstructTableRowFrame ()
#25 nsCSSFrameConstructor::TableProcessChild ()
#26 nsCSSFrameConstructor::TableProcessChildren ()
#27 nsCSSFrameConstructor::ConstructTableRowGroupFrame ()
#28 nsCSSFrameConstructor::TableProcessChild ()
#29 nsCSSFrameConstructor::TableProcessChildren ()
#30 nsCSSFrameConstructor::ConstructTableFrame ()
#31 nsCSSFrameConstructor::ConstructFrameByDisplayType ()
#32 nsCSSFrameConstructor::ConstructFrameInternal ()
#33 nsCSSFrameConstructor::ConstructFrame ()
#34 nsCSSFrameConstructor::ProcessChildren ()
#35 nsCSSFrameConstructor::ConstructFrameByTag ()
#36 nsCSSFrameConstructor::ConstructFrameInternal ()
#37 nsCSSFrameConstructor::ConstructFrame ()
#38 nsCSSFrameConstructor::ContentAppended ()
#39 StyleSetImpl::ContentAppended ()
#40 PresShell::ContentAppended ()
#41 nsDocument::ContentAppended ()
#42 nsHTMLDocument::ContentAppended ()
#43 HTMLContentSink::NotifyAppend ()
#44 SinkContext::FlushTags ()
#45 SinkContext::DidAddContent ()
#46 SinkContext::CloseContainer ()
#47 HTMLContentSink::CloseContainer ()
#48 CNavDTD::CloseContainer ()
#49 CNavDTD::CloseContainersTo ()
#50 CNavDTD::CloseContainersTo ()
#51 CNavDTD::HandleEndToken ()
#52 CNavDTD::HandleToken ()
#53 CNavDTD::BuildModel ()
#54 nsParser::BuildModel ()
#55 nsParser::ResumeParse ()
#56 nsParser::OnDataAvailable ()
#57 nsDocumentOpenInfo::OnDataAvailable ()
#58 nsHTTPFinalListener::OnDataAvailable ()
#59 InterceptStreamListener::OnDataAvailable ()
#60 nsHTTPChunkConv::OnDataAvailable ()
#61 nsHTTPServerListener::OnDataAvailable ()
#62 nsOnDataAvailableEvent::HandleEvent ()
#63 nsStreamListenerEvent::HandlePLEvent ()
#64 PL_HandleEvent ()

Comment 24

[alla]

Ok. I'm onto this. There are several reasons, first of all there is to much
Xserver communication (waiting for a result from the server, like can be seen in
the backtrace by Andreas Franke). There is also a O(n^2) algorithm in
nsView::HandleEvent() (see bug 49175, where i added a patch for it).

I'll continue to work on this.

Comment 25

[alla]

Ok, In bug 49300 I've added a patch that fixes one of the Xserver communication
hotspots.

Comment 26

[alla]

In the current cvs tree, with the patch in bug 49175, the second patch in 49300
and this stupid hack (which breaks popup placement):
Index: nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.291
diff -u -r1.291 nsWindow.cpp
--- nsWindow.cpp	2000/08/17 03:29:06	1.291
+++ nsWindow.cpp	2000/08/18 13:25:29
@@ -2657,7 +2666,11 @@
       nsRect oldrect, newrect;
       oldrect.x = aX;
       oldrect.y = aY;
-      mParent->WidgetToScreen(oldrect, newrect);
+
+      // ALEX: *BAD HACK* (remove WidgetToScreen call as it costs a lot in
Xserver comm)
+      //mParent->WidgetToScreen(oldrect, newrect);
+      newrect = oldrect;
+
       gtk_widget_set_uposition(mShell, newrect.x, newrect.y);
     } else {
       gtk_widget_set_uposition(mShell, aX, aY);

I can load the no outer table example from disk in 52 seconds on a PII 450 Mhz.
This is a lot better than the previous 25 minutes. The main part of the time is
now used by nsViewManager2::ProcessPendingUpdates() which seems a bit harder to
fix. See the attached jprof profile.

The reason for the stupid patch is that the placement of the popup calls
gdk_window_get_origin() a lot of times which stalls the X communications a lot.
This would be fixed (correctly) by doing lazy dropdown creation. It seems
[e-mail] is working on this (see comments in 39544).

Comment 27

[alla]

Attachment: A jprof profile loading a file with 80 lines of dropdowns.

Comment 28

[rods (gone)]

I am trying to get some traction on Bugs 49175, 49300, and this one.

Comment 29

[ckritzer (gone)]

PDT: Nominating for nsbeta3_
Reason:  Tables and forms are prevalent in the web; tables have been problematic 
since early days (Mosaic 1.0, I believe).  Important to have them work as 
smoothly as IE.

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can't we just cache the widget's screen offset and avoid having to ask the X 
server every time?

Seems to me that, since X-server-roundtripping is such a bad idea, the widget 
should cache everything in sight and only flush the cache between X events (or 
something like that).

Comment 31

[alla]

Yes, we could cache it. This would bloat nsWidget though, something that might
not be very smart. I've been thinking about caching it in nsWindow only, as that
is the one used here. I'll look into it.
 

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

8 bytes per widget isn't much. If you have a lot of widgets I think you'll find 
that 8 bytes per widget is a very small percentage of the total memory load.

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Actually, I've got another idea. Why don't we hack the Mozilla nsIWidget layer 
to lazily create the underlying native widget --- i.e. only create the widget 
when it's shown? Better yet, when an nsIWidget is hidden we could move its 
native widget into a shared cache, and grab a widget from that cache when an 
nsIWidget is shown. This would totally solve the resource issues in bug 39544 
too.

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I mean, it would totally resolve the resource issues because even if you have 
10,000 comboboxes, you only display one of them at a time so you only need one 
native widget. Likewise, XUL menus only really need 2-3 widgets (depending on 
the nesting depth of the submenus).

Comment 35

[rods (gone)]

I am definitely for caching the coords in the widget, we have been reducing the 
number of widgets so the overhead shouldn't be a lot.

Comment 36

[ekrock's old account (dead)]

Marking as [nsbeta3-] a number of bugs that were already marked Future (but not 
[nsbeta3-]) because the Netscape engineer the bug is assigned to is 
overburdened. If you disagree with this decision, please provide information 
about customer and user impact, but please do not clear the [nsbeta3-] unless 
you are reassigning the bug to yourself and committing to a fix within the 
nsbeta3 timeframe.

Comment 37

[alla]

Attachment: Patch that implements position cachine in nsWindow

Comment 38

[alla]

Ok, I've added a patch that does caching of window coordinates in nsWindow. It
works well in my tree, and improves performance in the testcase. (Although
performance sucks again since the O(n^2) fix in bug 49175 has been reverted.)

rods, can you take a look at the patch and try to get it in?

Comment 39

[rods (gone)]

If I put this patch in (id=13865) are there any other patches I need to put in? 
Or will this help out here and hopefully fix Bug 48230?

Comment 40

[alla]

Well. If you put in this patch and the one in bug 49300 all the Xserver
bottlenecks in this bug are fixed. The other problem is bug 49175, but fixing
that lead to the problems described in bug 50335, so it had to be backed out. It
seems that [e-mail] will try to fix it in his rewrite of nsViewManager
though.

This will not fix bug 48230.

Comment 41

[rods (gone)]

renominating for nsbeta3, it was my fault i still had it futred I am working on 
this one with alex

Comment 42

[rods (gone)]

The patch file is out of date, I will attach a new patch for for this patch plus 
49300.

Comment 43

[rods (gone)]

Attachment: updated patch for this bug and it includes patch from Bug 49300

Comment 44

[Stuart Parmenter]

sorry for my delay.  this patch looks good to me.  go ahead and check it in. 
r=pavlov

Comment 45

[Kevin McCluskey (gone)]

Marking nsbeta3+

Comment 46

[Daniel Bratell]

The patch seems to be GTK-only, but this page kills Mozilla on Windows as well.

Comment 47

[alla]

Daniel: That is due to bug 49175

Comment 48

[rods (gone)]

Since it still take a lot of time to render this page, I am not going to mark 
this fixed. I have removed nsbeta3 because the patch has been checked in and it 
is much improved. 

I am not sure it it still needs the "crash" keyword, but it probably does.

Comment 49

[rods (gone)]

forgot to set to "future"

Comment 50

[bsharma]

Updating QA contact.

Comment 51

[John Unruh]

Just loading this page causes a crash on Win98, 10/3 branch build. Talkback ID
18521273

Comment 52

[bsharma]

Build: 2000092711 MN6
Platform: WinNT

Loading the testcase provided in the "url" and the attached testcase, both hangs  
the browser.i.e., the browser does not respond and I have to close it through 
the Task Manager.

Build: 2000092909 MN6
Platform: Linux

The attached testcase loads fine and the "url" tesetcase takes about 10 min to 
load.

Comment 53

[Kevin McCluskey (gone)]

Rod indicated that the correct way to fix this will be to lazily instantiate the
combobox dropdowns, but that is too big a change for rtm.

Marking rtm-.

Comment 54

[rods (gone)]

maybe fixed with lazy dropdowns

Comment 55

[Bernard Alleysson]

I hope so.

I have a portfolio at www.hsx.com with more than 700 stocks
so my portfolio page have more than 700 combo-boxes.

It takes more than 5mn on a PIII-600 (Win2k) to render the page
and after that scrolling into the page is not usable :-(

This is dogfood for me at home.

Comment 56

[rods (gone)]

waiting for XBL form controls

Comment 57

[Vladimir Ermakov]

QA Contact Update

Comment 58

[Bernard Alleysson]

just some thoughts:

I see improvement in the recent build:
loading my portfolio (now with about 900 combos ;-) takes too much time
but after that now I can scroll in the page

I think the fix was from [e-mail]
(the cvs log comment is:
"
Fixing bugs 64523, 50018, 57626, 59024, 61413  and probably others, making
the document and form JS engine resolve hooks find what they're supposed to
find, and nothing more, making the element-by-name and element-by-id lookup
in the document be hashtable based to avoid walking the whole DOM tree over
and over again when resolving names on the document object and also on form
objects. This is an order of magnitude speedup for pages that contain a
large number of form controls, such as hotmail and aol mail. Also did a
bunch of cleanup here n' there. r=[e-mail],
sr=[e-mail]."

is this relevant to this bug ?

in fact the initial display of the page from the internet (64kbit/s
connection)is quite fast but it stops (with 100%CPU and throbber blocked)
several times during the page loading as it renders more combos)

maybe the display time would be better if the render was done *once* when the
page has finished loading ?

when the file is saved locally page loading takes 1'20 at 100%CPU

maybe this is because the data is coming too fast from the disk and the
threshold used to render the combos is too small and the time is wasted doing
incremental rendering ?

I'll attach my local file (zipped because it is 1Mo HTML)

Comment 59

[Bernard Alleysson]

Attachment: Portfolio with many combos (#900)

Comment 60

[Randell Jesup [:jesup] (needinfo me)]

Attachment: jprof of an aborted (5 min) load of this page

Comment 61

[Randell Jesup [:jesup] (needinfo me)]

The jprof attached (warning, >800K) shows that ~70% of the time to load this
page is in nsView::GetChild and ::GetNextSibling.  (actually, I gave up waiting
after ~ 5 minutes).  These are all coming from within events dispatched by
CreateWidget(), and GetChild is called directly from nsView::HandleEvent() (with
is 84% including decendants)

There are some other hotspots, but this is a good place to start.

I suggest removing the "future" from this.

Comment 62

[Cathleen]

issue raised in performance meeting today. we would like to resurrect this bug
for 0.9.5, and figure out how much work is needed to fix it...

finding that loading a large page, a lot of time is spent on nsView::GetChild
and ::GetNextSibling.

rods can you investigate for a performance improvement?  

thanks!!!

Comment 63

[rods (gone)]

The best approach would probably be lazy instantiation (see Bug 62568 for 
analysis)

A couple of things I noticed with a little bit of research:
nsView uses a linked list so all GetChild calls are linear, so as each select is 
added 5 more views get added to the list that is searched each time.

As each select is created it dispatches a CREATE event and an event when the Z 
order is set.

I have an example with 200 selects and I have these different timings:
I have done several tests, some with the nsView using a nsVoidArray instead of 
the linked list. And some tests with suppressing the two unneeded events from 
when the ScrollingView creates it's window and sets the Z-order.

From start up (not in the debugger) until the selects appear (wall clock)
VoidArray    Linked-List  % Savings
------------------------------------
6.25            7.90         12%

These timings were all in the debugger and cannot be compared to the timing 
above (these are wall clock timings):

Suppress Events   VoidArray     Suppressing
VoidArray           Only           Only          Current Tip
-------------------------------------------------------------
7.47              7.89             8.23             10.02
25%                21%             18% (savings)

When loading the 200 selects the GetChild was visited 253,559 times, as stated 
above an additional 5 new views for each new select.

When suppressing the events the numbers of visits dropped to 115,513 which is a 
55% savings in the number of calls to GetChild.

Summary
----------
Most pages have very few views and the linked-list of views does not hamper 
performance. When there are a lot of selects, there are 5 new views for each 
drop-down of each new select. This ends up creating a very long list of views 
that needs to be search everytime inside GetChild.

Also note that event processing is a little faster with the VoidArray (somewhat 
noticable) because the look up via the array is faster.

The VoidArray impl would take up more memory, but since there are usually very 
few views it shouldn't impact the overall footprint by a lot.

In Bug 62568, the CPU time for 200 selects was 10.65 for the Tip and 3.1 for 
lazy instantiation (LI), which translated into a savings of 71%. 

Comment 64

[Randell Jesup [:jesup] (needinfo me)]

Using voidarrays for nsViews is a good idea (though not a final solution, as you
said).  The overall cost is minimal, since while the array costs bytes, you save
space in each view structure.  The overhead is basically 2 words plus the amount
of unused space in the array (normally less than 50%, average 25%).  If we
forsee removing large numbers of views from a list without destroying it, we
should consider Compact()ing it _occasionally_ or if it shrinks a lot.  I don't
think this is an issue, however.

Comment 65

[Randell Jesup [:jesup] (needinfo me)]

Rods: Are we still targetting 0.9.5 for either lazy instantiation or using
nsVoidArrays (or nsAutoVoidArrays)?  Both appear to be wins (the nsVoidArray
saves time more generally, while Lazy Instantiation saves a lot in this
particular instance.  (It might help in cases like bugzilla query.cgi too.)

Comment 66

[Randell Jesup [:jesup] (needinfo me)]

I doubt lazy instantiation is going to make it for 0.9.5.  any chance of the
voidarray change you tested (and maybe the supression) making it?  

Comment 67

[rods (gone)]

moving to 0.9.6

Comment 68

[Madhur Bhatia]

on win2000 and linux 7.1 - hangs the browser when trying to upload the testcase 
provided in the url

on linux 7.1 - the 'no outer table in example' testcase is uploaded without a 
hang, but it is slow.

works fine on Netscape 4.77.

Comment 69

[Ron Cemer]

Attachment: Form with 4000 input elements

complex forms which sometimes have hundreds of input elements per form.  The
attached HTML form has 4000 input elements.  It loads in under one second on
IE5.5, but takes 42 seconds to load using Mozilla 0.9.6.  I'm testing on an
800-MHz Pentium III with 384 MB of RAM and nothing else going on.

This is a genuine show-stopper, and it's keeping me from being able to deliver
a very large intranet web application which is mission-critical to the success
of a corporation.

Any help to fix this would be greatly appreciated.

Mozilla's functionality is great, but its speed is terrible in this area.  Can
anyone help, or is all hope lost?  It's been over two years now that Mozilla
has failed to overcome its speed issues.  The Open Source community needs a
fully-functional but FAST browser to compete with IE.  Otherwise, M$ is going
to continue to dominate.  Is there a way we can light a fire under this issue
and get it resolved quickly?

Thanks!

Comment 70

[Kevin McCluskey (gone)]

The reason this bug was marked future is because the plan is to completely
replace the current form element implementation with an XBL binding which would
include support for both XUL and native widgets. bug 58317

The optimization that is necessary for the current frame-based form elements
would not apply to the XBL-XUL implementation, so it would be wasted effort.

Comment 71

[Randell Jesup [:jesup] (needinfo me)]

Bryner says he plans to hit 58317 for 1.0 or before; it's gated on bug 97062
(dependency is not marked).  If it's not going to be done soon we'll need to
patch around the problem.

Comment 72

[Kevin McCluskey (gone)]

I don't think this bug is an issue any more. I loaded the 4000 input element 
test case on WINXP with 750Mhz machine using IE 6.0 and it takes 40 seconds to 
completely load. I also used a cvs release build of Mozilla from today and it 
took 42 seconds. 

The checkin for bug 112525 significantly sped up the loading of pages with 
large numbers of comboboxes.


Marking FIXED.

Comment 73

[Ron Cemer]

*** WRONG ***.  This bug is NOT fixed.  IE 5.5 loads the 4,000-element form in
one second.  Just because IE6.0 may be slower doesn't give us an excuse to be
slow also.  In fact, I find it hard to believe that IE 6.0 is slower than IE 5.5.

Please re-open this bug so it can really get fixed, or I'll be forced to submit
another.  This is a HIGH PRIORITY!!!

Copping out on serious bugs is one of the reasons why IE is stomping Netscape's
butt.  Let's not fall into that trap anymore.

Thanks!

Comment 74

[Kevin McCluskey (gone)]

Note: Nav 4.79 takes 32 seconds to load the 4000 input element test case, using
WINXP 750Mhz machine.

Comment 75

[Kevin McCluskey (gone)]

Opera 6.0: Takes 43 seconds to load and is unusable after loading the test case
on WINXP. Opera takes around 10 seconds to initially display anything.

I can not test IE 5.5 because it will not allow me to install it on WINXP.
Someone else we need to test it on IE 5.5

Ron: Are you looking at only the time it takes to initially display or the
entire document load? Can you actually scroll to the bottom a page within a few
seconds and have it display the item 3999?

Comment 76

[Kevin McCluskey (gone)]

Ok. I was able to reproduce on IE 5.5. It does load the 4000 input element
testcase almost immediately. re-opening

Comment 77

[Ron Cemer]

Thanks!  I really appreciate it.

If anyone knows where I could look in the source code to start trying to fix
this, please forward info to me at [e-mail] and I'll try to help find
out what's going on to cause the slowness.  I'm new to the Mozilla source code,
but I'm pretty good at optimizing code for speed without breaking functionality.

Comment 78

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Woah, so now it's not enough to just be faster than IE6, we have to be faster
than IE5.5 too on pages where IE6 is slower? That really raises the bar.

Comment 79

[Randell Jesup [:jesup] (needinfo me)]

IE 5.0 Win98 233MMX 64MB - 4000 elements takes 14.75s.  Quite fast, considering,
and the first page of elements were available to interact with within a second. 
So it's not just IE 5.5 that's fast on this.  On the first attachment ("no outer
table"), it took 14.1s.

mozilla 2001113003 233MMX 64MB - 4000 elements takes 157s.  Over 10 times as
long, and for all that time there was no display and no responsiveness, not even
the throbber.  Also, the disk was getting hit quite often for most of the load,
so I think part of the issue was bloat.  On the first attachment ("no outer
table"), it too 608 seconds, or ~40 times longer, and there was no disk
activity.

That said, since many browsers have some trouble with the 4000 element test, I'm
not _that_ worried about it.  I am worried about the 300 and 500 and even 900
element versions, and I'm worried about no being able to interact with the 4000
element version for the entire time it's loading.  This is one of the many
things that blocks our UI thread and really shouldn't, though I imagine it's
years too late to worry about that.

Comment 80

[Kevin McCluskey (gone)]

I rebooted, cleared my cache on IE6 and I was able to get IE6 to load the
page in about 1 second.


Here are the numbers I see now

4000 input type=text
--------------------
4.x 30 sec
Mozilla 28 sec
IE 6 1 sec

select (combobox) loading 300 comboboxes
----------------------------------------
4.x 5 sec
Mozilla 11.8 sec (Fixing bug 112861 would get this down to around 8 secs)
IE 4 sec

4000 input type=checkbox
------------------------
4.x 40 sec
Mozilla 3.2 sec
IE  1 sec

4000 input type=radio
----------------------
4.x 20 sec
Mozilla 22 sec (Changing nsFromFrame::GetRadioInfo to use a hashtable would get
this down to around 3sec)
IE  1 sec

4000 input type=button
----------------------
4.x 40 sec
Mozilla 4 sec
IE  1 sec


So in conclusion the real problem spot is input type=text.

Comment 81

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Aaaah, OK. Now things make sense :-).

IE5.5, at least, uses native widgets for comboboxes but not for edit controls,
which probably explains the differences between control types in IE.

> though I imagine it's years too late to worry about that.

Nah. We should be able to introduce finer-granularity interruptibility in layout
without rewriting the world, but don't expect that before 1.0.

What would REALLY rock here is if we could lazily create frames for stuff we
know isn't scrolled onto the scren. But that's another post-1.0 optimization.

Comment 82

[Bernard Alleysson]

"Changing nsFromFrame::GetRadioInfo to use a hashtable would get
this down to around 3sec" (instead of 22 sec)

Is there a bug number for this one ?

Comment 83

[Kevin McCluskey (gone)]

Note: With the outer frame it still take 605 seconds to load on 750Mhz AMD
machine running WINNT. Without the outerframe it takes 58 seconds. 

Comment 84

[Ron Cemer]

I noticed yesterday that if I create a 4,000 input element form in which all
input elements are hidden, it still takes a *LONG* time (over 30 seconds) to
load the page.  BUT, if I remove all whitespace between input tags, such that
the closing bracket of one input tag is immediately followed by the opening
bracket of the next, then the page loads in less than two seconds, which is
pretty quick.

Comment 85

[NilsE]

With a current nightly build, the problem is still there. As a side note, the
repro URL has the problem that all pull-down menus in the table appear several
cm  to the right of the button. That is not true for attachment #8771 [details], where the
menu alignment is correct. Is there any relation to bug 74888?

Comment 86

[Russell Odom]

*** Bug 137275 has been marked as a duplicate of this bug. ***

Comment 87

[Markus Hübner]

Using trunk build 2003020308 on winxp pro sp1,1.1ghz,512ram this still freezes 
mozilla.
Is this related to bug 168157 ?

Comment 88

[Lars Petersen]

See this also http://forums.mozillazine.org/viewtopic.php?t=34492
It refers to this page http://weird.peytz.dk/test/bigform.html
Which has a big form in a big table - Mozilla / Firebird is a lot slower than
i.e. IE in loading/rendering it...

Comment 89

[Kevin Berkheiser]

I think the crash keyword can be removed.  I just tested this and the original
link loads (with no images though), and all the testcases load.  I had no crashes.

All these tests are still slow.  The 4000 input element testcase took 25 seconds
on my AMD Athlon XP 3000+ with 1 gig or RAM.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

Comment 90

[Jeremy M. Dolan]

4000 element case takes 65 seconds on my Linux P2/266. None of the attachments
seem to crash anymore, though. Removing crash keyword and myself from CC.

Comment 91

[Wayne Mery (:wsmwk)]

no longer exists - http://weird.peytz.dk/test/bigform.html

20 seconds - http://www.lysator.liu.se/~alla/moz/rules.html -- SM and FF render in same amount of time as IE

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Comment 92

[Wayne Mery (:wsmwk)]

closing WFM 2.0.0.5 Vista. IE still comparable