60137 - <select multiple> with 8000 options DOG SLOW

Status: VERIFIED FIXED

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

Description

[simon]

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
BuildID:    2000080923

If you have a <select multiple> with 8000 options in Mozilla it becomes too slow
to work with. Netscape 4.5 on the other hand doesn't
have a problem whatsoever with this.

Reproducible: Always
Steps to Reproduce:
1.see description
2.
3.

Actual Results:  see description

Expected Results:  be alot more responsive

<select multiple name="line_sel" size="3" class="linesbox">
<option value="all" selected>All
<option value="57-555-0">555-0
<option value="58-555-1">555-1
<option value="67-555-10">555-10
<option value="157-555-100">555-100
<option value="56-555-1000">555-1000
<option value="1057-555-1001">555-1001
<option value="1058-555-1002">555-1002
<option value="1059-555-1003">555-1003
<option value="1060-555-1004">555-1004
<option value="1061-555-1005">555-1005
<option value="1062-555-1006">555-1006
... and so on ...
</select>

Comment 1

[James Lariviere]

I think that this is a dupe.

Moving over to html form controls.

Reporter have you viewed with a more current build?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

-> HTML Form Controls

Comment 3

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

Someone should profile this.

Comment 4

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

Also, someone please confirm with a newer build.  Reporter: Please upload the
source for the page as an attachment.

Comment 5

[simon]

Attachment: this html makes mozilla dog slow

Comment 6

[Keyser Sose]

Yup seeing this on Mozilla Build #2000112704 M18 Trunk Build, Win 98, PC. I also
lost the ability to type in the dialog boxes here as well and had to restart
Mozilla.

Comment 7

[rods (gone)]

I agree, but how useful is an select with 8000 options? I am sure this is a dup 
of other select performance bugs.

Comment 8

[Kevin McCluskey (gone)]

Setting milestone to future

Comment 9

[Vladimir Ermakov]

QA Contact Update

Comment 10

[John Morrison]

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

Comment 11

[Mats Palmgren (inactive)]

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

Comment 12

[rcummins]

Seeing this on win95, build 2001081108.  http://www.burlco.lib.nj.us/moz/select/
contains a simple form with a select that contains 10000 option tags.  (Would
this ~260kb file have been too big to attach to this bug?)

The following is a chart of page load times (in seconds) with an increasing
number of option tags:

1000  - n/a	3.1
2000  - 5.4	5.3
3000  - 7.5	31.6
4000  - 9.7	55.5
5000  - 12.1	105.5
6000  - 14.1	156.0
7000  - 16.5	210.3
8000  - 18.7	270.3
9000  - 21.9	345.2
10000 - 25.1	415.8

The first column is the # of option tags in the page being loaded, the second
column is the load time *when I increment the number of option tags by 1000 and
click the reload button* and the third column is the load time *when I increment
the number of option tags by 1000, click in the URL location bar and hit enter
to reload the page*.

Another weirdness is that, when I click in the URL location bar and hit enter to
reload the page, then switch to another window that partially conceals the
Mozilla window, the load time for the 10000-option-tag page falls back down to
around 30 seconds, instead of the 'expected' 400 or so seconds (IE5.5 loads it
in under 5 seconds).

Hope this gives someone a clue.

Comment 13

[Tom Mraz]

Seems to be worksforme on Linux 2001092021. Please test on other platforms and
resolve it.

Comment 14

[John Keiser (jkeiser)]

Adding a "block" because this becomes bad again with my patch.

Comment 15

[John Keiser (jkeiser)]

OK, selection is no longer dog slow on this HTML with the first bug 34297 patch.
 Now adding a dependency.

Actually selecting the options by clicking on them, which I assume people are
talking about, is almost instant at the beginning of the list and takes up to
1/3-1/2 second at the end of the list (due to the fact that the frame has to
figure out what the option index is--and that's calculated by speeding through
the array to find the option).

Even without the patch, in current CVS, it only takes 2-3 seconds (1GHz Athlon,
256M RAM).

Comment 16

[John Keiser (jkeiser)]

So is this dog slow or not?  What is acceptable?

Comment 17

[John Keiser (jkeiser)]

OK, selection now takes under a second on my *debug* build (so it's got to be a
lot faster on the opt build).  JST made a checkin tonight, in fact, that really
cured it (removing a spurious GetIndex() from
nsHTMLOptionElement::SetSelectedInternal().  The page takes longer to load now,
but that's a bug 108232 issue, not an issue for here.

Comment 18

[Madhur Bhatia]

verified fixed on 
win2000 buildID: 2001-11-08-06-trunk
mac 9.1 buildID: 2001-11-08-08-trunk