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.

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.

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).

I crashes in nsWindow::CreateWindow and then crashes MSDEV

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.

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.

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?

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

proposing as nsbeta2 since it's a crasher

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.

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.

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.

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.

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.

See also: bug 39573 and bug 39573.

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".

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!

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)?

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.

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.

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).

> 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).

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 ()

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.

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

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 rods@netscape.com is working on this (see comments in 39544).

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

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.

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).

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.

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.

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.

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).

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.

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.

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?

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?

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 roc+moz@cs.cmu.edu will try to fix it in his rewrite of nsViewManager though. This will not fix bug 48230.

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

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

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

Marking nsbeta3+

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

Daniel: That is due to bug 49175

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.

forgot to set to "future"

Updating QA contact.

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

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.

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-.

maybe fixed with lazy dropdowns

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.

waiting for XBL form controls

QA Contact Update

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 jst@netscape.com (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=pollmann@netscape.com, sr=vidur@netscape.comI." 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)

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.

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!!!

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%.

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.

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.)

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?

moving to 0.9.6

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.

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!

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.

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.

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.

*** 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!

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

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?

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

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 ron@roncemer.com 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.

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.

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.

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.

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.

"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 ?

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.

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.

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?

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

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

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...

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

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.

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

closing WFM 2.0.0.5 Vista. IE still comparable