We wrote some pages using heavily on form with many many controls, and that sometimes make browsers crash. So we wrote a page with 1500 combo boxes. The page http://www.csie.ntu.edu.tw/~b7506051/ControlsTest.html contains a table with 100 lines, each with 15 combo boxes in it. Browsing this page on Windows 98 almost make system reporting "Run out of system resources" all the time, but at least on Windows NT, we can browse it sucessfully (and the loading time is not long) with Netscape 4.6, Internet Explorer 5; but none of the mozilla versions could get it work. Maybe this is not a bug, but... I think it'll be much better if mozilla can handle such tables :)

Ok, so first off: Don't do that :) Each select has two dropdown windows, one for floating and one for clipping. I would imgaine it is the number of windows that is killing it. Setting to M18, perf keyword

loading that page in mozilla crashed my windows 98 system soon after the "out of system resources" error occured. by the way, loading the same page in ie 5 displayed the error as well, and almost led to a crash.

I was wondering when anyone would ever use a form with anywhere near 1500 <SELECT>s, and then I saw bug 39573. The performance problem seen here must be part of the problem seen there. Tested the attachment and two testcases based on it with NN 4.7, IE5, and today's nightly binary on WinNT 4.0. The system has 128MB memory, 150MB swap, a K6-300 processor, and had several tasks running consuming about half the memory and on third of the swap. NN 4.7: for original testcase: used all available CPU for ~ 1 minute, slowing but not freezing system; once page loaded, scrolling took ~0.3s. IE5: for original testcase: used all available CPU for ~ 1 minute, slowing but not freezing system; once page loaded, scrolling took ~12s first time exposing a region, ~1s thereafter. Mozilla 2000-05-17-08-M16: for original testcase: used all available CPU for over 1 hour; page never diaplayed; system almost frozen, but not quite. For 750-select testcase: used all available CPU for ~ 10 minutes; system slowed but did not freeze; performance scrolling better than NN 4.7, ~0.1 second displaying new regions first time. For 300-select testcase: used all available CPU for ~ 1 minute; system slowed but did not freeze; performance scrolling better than NN 4.7, ~0.1 second displaying new regions first time. Testcases for 750 and 300 selects follow.

Sean, thanks for doing the further tests. The results are facinating. One approach would be not to create a dropdown (list and window) for any combobox once there were more than 300 of them on a page. Then create the dropdown when the user clicks on it. The first click would be slower, but after that it would be fine.

Chris might be able to provide some interesting feedback. Lazily instantiating lists sounds like the right plan, but it's unclear how you should decide when to do it. For a single select, setting a threshold like 50 or 100 sounds good. How many real pages would this effect? The more interesting case is when there are many selects on a single page, and each one has less than the threshold number of options. Should we keep some sort of per-document (pre-presshell?) counter, and stop pre-building list frames when it is hit?

This is an extreme edge case. Don't think we'll find real pages with this many separate SELECT menus. Marking FUTURE; we can return to this if we deal with all the real-page issues for FCS.

A naive question, why create any combobox at all before a combobox is selected? Can it contain elements that take noticable time to render?

We have been creating the dropdown so it gets layed out correctly so we know what size to make the combobox. I have some code ifdef'ed out that can do sizing of all the option element's text without creating the dropdown. Then we will "lazy instaniate" the dropdown when someone clicks on it. The first you click it will be slower than subsequent clicks. The problem is making sure the sizing algorithm match exactly what layout would do.

> Why create any combobox at all before a combobox is selected? I'm not writing the code, so I don't know the real reasons, but another possible reason is that creating them all at the beginning makes bugs involving many comboboxes more visible. If mozilla always waits until the combobox is pulled down, then there will be memory/resource/slow-loop bugs that appear only when a person (or some javascript) decides to pull down a large number of comboboxes.

rods, are you still working on the lazy instantiation of comboboxes? The DO_NEW_REFLOW code doesn't compile. I need this bigtime on linux, because instantiating all the dropdown windows means you stall on the Xserver communication doing gdk_window_get_origin(). This *really* kills performance. I have profiles where waiting for the xserver shows up as 70% of the time to load a page with dropdowns. (This is using a remote X display.)

Lazy instantiation of comboboxes was deemed too risky and too time consuming for the first release. We will try to get it in for 6.x or we will be switch over to XBL based comboxes that are used in the UI.

Updating QA contact.

This will get fixed with lazy dropdowns, changing priorities, setting dependencies

may wait for XBL form controls

QA Contact Update

Any progress with this bug?

With the checkin for bug 112525 performance on WINXP is acceptable. It cut the load time for the 300 select testcase from 48 sec down to 11.8 sec. Changing platform to Linux, since it now acceptable on WIN32.

Resolving as fixed. If there is still an issue with a large number of selects when running using a remote X display, please file that a separate bug.

On my machines the behaviour is better on linux then it is on windows, and the machines are the same, except perhaps for the fact that windows has more applications opened... The 300 and 700 (does it have 700 or both of them are the same size?!) testcases load around 10-15 secs, but the first testcase does not load on windows 98, and makes it run out of resourses. On Linux it loads in 10-15 seconds just like the other two... The bug definition from the summary is still not fixed, the browser runs out of resourses and hangs.... Changing OS to windows 98 I dont know how to judge this, but the original problem is still present on windows 98, even though loading speed for the additional testcases has been improved. I'm reopening.

Marking this ancient bug as WORKSFORME. I do not see a high memory allocation whatsoever using that testcase.