82924 - Javascript menus function very slowly

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[ed]

From Bugzilla Helper:
User-Agent: Mozilla/4.61 [en] (X11; I; Linux 2.2.12-20 i586)
BuildID:    0.9

The Menues on the webpage http://eulox.net implemented in Javascript function in
Mozilla much slower than they do in Netscape.

But they work correct, what is a nice thing!!

Reproducible: Always
Steps to Reproduce:
1. Go to the webpage http://eulox.net
2. move with mouse over the menue bar so that the menues drop.
3. move with the mouse over the droped menue, each menue entry should be
highlighted. This highlighting happens very slow. 

Actual Results:  Slow performance

Expected Results:  as fast perormance as in Netscape or IE

relates maybee to bugs 40988, 65509, 65510

Comment 1

[Doron Rosenberg (IBM)]

what sort of system are you on? I don't see any difference on my p2 400 256 ram

Comment 2

[ed]

It was running on a 400 MHz P3 with 256MB RAM Linux Kernel 2.2 Machine displayed
as X11 remote over a local 100 MBit LAN on a 400Mz P3 128 MB RAM also under
Linux Kernel 2.2. 

(The remote Display should not cause the described effect, but it might be)

Comment 3

[Oliver Klee]

Over to JavaScript Engine, adding perf keyword.

This works fine for me on 2001052608 Win2k on an AMD K6-II+ 500 with 256 MB RAM.

Have you activated your memory cache and disk cache (Edit/Preferences/Debug to
enable and Edit/Preferences/Advanced/Cache to set the cache size)?

Comment 4

[James Green]

This operates slowly for me too. I'm on a K6-2 300Mhz with 256Mb ram, building
from the tip with --disable-debug --enable-optimize=-O2. The menus react
approximately 2x slower than when in Nav4.7. Marking new. I suspect this can be
linked to various speed problems, some XP and come Linux-specific.

Comment 5

[Chris Hiner]

Dup of bug 65509 or bug 78826?

Comment 6

[timeless]

page appears down, please attach a testcase or something. either bug looks like 
a reasonable dupe given i can't actually see the page...

Comment 7

[Doron Rosenberg (IBM)]

interestingly enough, this seems to be slower for me on win32 (2001052320) than
4.76. On linux I did not notice any difference.

I wonder if we have any "DHTML is slow" meta bug.

Comment 8

[James Green]

Doron: yes, we're blocking it :).

Comment 9

[Johnny Stenback (:jst)]

There's nothing we can do about this now, marking Future for now...

Comment 10

[José Jeria]

Another good example:
http://www.likno.com/

Comment 11

[Dimitrios]

Moving over pulldown menus of both http://www.likno.com/ and http://eulox.net
works fine with build 2001102503, Win98, K6-III/400, 192MB. Is this time to
close the bug?  :-)

Comment 12

[Jens-Uwe]

www.eulox.net works fast here (P3/500). marking WFM
reporter: please reopen, if you disagree :-)

Comment 13

[James Green]

Wholeheartedly disagree. Did you compile your builds --include-speed or something?

I just tested as follows:

* Mozilla build taken from the tip today at 0800GMT, with gcc2.95.4, using the
following options:
ac_add_options --disable-debug
ac_add_options --enable-optimize=-O2
ac_add_options --enable-elf-dynstr-gc

* Netscape 4.76

Both on Debian Sid Linux, kernel 2.4.9; machine is AMD k6-2 300Mhz, 256MB RAM,
512MB swap. Plenty of memory free during testing.

In Netscape 4, menus reacted 'instantly.' No noticable delay between my
switching between entries and the final drawing on screen.

In Mozilla, each menu change took 1-2 seconds, very often a glide over multiple
entries caused only a few of the entries to be lit up, i.e. several were
skipped. Very much less than what most users are used to and expect.

Repening. *PLEASE* when you test performance stuff use both Linux (gcc can't do
compiler optimisations as Mac/Windows ones can due to patents) and a two year
old box minimum (300Mhz at most). I'm also requesting mozilla1.0 consideration;
not vital but that depends what our priorities are.

Comment 14

[Pascal Chevrel:pascalc]

I condirm that the problem hasn't been resolved on Win32 either !! On my
K6-2-300, 256 Mo Ram, Win98SE and Build 201102403, I have the same slowliness
James experimented with Linux. When  you put your mouse on eulox.com DHTML
links, there is a 1 second delay before the menu appears. With NS4.78, this is
instantaneous. CPU usage when moving the mouse over the DHTML menu links is
between 50 and 60%. Using NS4.78, it is between 15 and 20%. likno.com DHTML
menus are so slow that they are amost unusable. 

Comment 15

[James Green]

Plat/OS All/All.

Comment 16

[Dimitrios]

pascal: aren't we talking about "Uber eiloch", "Leistungen" and "Service" menus?
I agree with James that this bug must be tested with slow machines but if my
K6-3/400 is so faster than a K6-2/300 (because of its 50% faster clock and fast
on die 256K cache), then bug summary should be "Javascript menus function very
slow on slow machines". I think this bug has nothing to do with >= 400MHz clock,
processors with on die cache.

Comment 17

[Pascal Chevrel:pascalc]

Dimitrios : I agree that my CPU is not very powerful compared to today's
machines, but I would not change the name of the bug because the problem is not
that it is slow on older machines but that it is slow compared to IE6 on the
same machine. Big cpu usage for a sluggish performance is not a normal
behaviour. Furthermore, I am no programmer, but I guess that it could also
affect the performance of Gecko on PDAs or any other devices which have even
slower CPUs.

Comment 18

[basic]

URL no longer works

Comment 19

[Andrew Hagen]

Editing for grammar.

Old Summary: Javascript menus function very slow

New Summary: Javascript menus function very slowly

Comment 20

[Andrew Hagen]

URL is now dead. Resolving as wontfix.