87165 - javascript is very slow for this example

Status: RESOLVED INCOMPLETE

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

Description

[Brian Degenhardt]

I've got some heiarchial menu code written in javascript that works fine with IE
and NS 4.XX but takes forever to render with mozilla.  During the rendering
time, mozilla sits at 100% cpu usage.

Comment 1

[Brian Degenhardt]

Attachment: html/javascript code that triggers this bug

Comment 2

[Brian Degenhardt]

Attachment: just the html file if you don't like zip

Comment 3

[Brian Degenhardt]

Some more info, it seems that this bug get's triggered more often when the page
is already cached, so if you clicked on the html attachment and nothing
happened, try it again, or try the back/forward button a few times to re-render it.

I'm getting brave here, so I'm gonna slap the 4xp keyword on this thing since it
works with the Netscape 4.76 on Linux that I've tested.

Sorry if I have the wong component.

Comment 4

[Aaron Kaluszka]

confirmed WinXP/20010619
adding perf keyword
Platform/OS->All

Comment 5

[Dimitrios]

I downloaded the test case and meaqsured the time needed for complete rendering
of the screen, after hitting the first arrow: 
NS4.7: 1.6 sec, checkboxes are not displayed
Moz 04-29-2001: 1.1 sec
Moz 0.9.5: 1.3 sec, no visual problems
Moz 2001102503: 1.1 sec, no visual problems
IE5.5: 0.7 sec, no visual problems

system spec: Win98, K6-III/400, 192MB ram.

Comment 6

[Brian Degenhardt]

Just an FYI, the first attachment is a .zip file that contains a more usable
testcase than the second example.

Comment 7

[Brian Degenhardt]

Also note that it's not slow if you run it off of local disk (IE: using a
file:// url).  The testcase has to be delivered by a remote webserver.

Comment 8

[Brian Degenhardt]

Attachment: jprof output JPROF_FLAGS='JP_DEFER JP_PERIOD=0.0020'

Comment 9

[Brian Degenhardt]

Attachment: jprof output JPROF_FLAGS='JP_REALTIME JP_DEFER JP_PERIOD=0.0020'

Comment 10

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 11

[Boris Zbarsky [:bzbarsky]]

Is this still an issue?  I'm not seeing any slowness on those testcases....

Comment 12

[Boris Zbarsky [:bzbarsky]]

OK, I can reproduce the slowness, depending on my cookie settings.  The
getCurrState() function seems to do this really slow walk over the cookie
string, and it's called a lot.  So doubling the length of the cookie string
doubles the execution time of this code....

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

I can still reproduce this with latest Fx3b5pre on WinXP.

Clicking on a category takes some time comparing to IE7 and uses 40% of CPU comparing to 4-6% in IE7

Comment 14

[Boris Zbarsky [:bzbarsky]]

Are your cookies exactly identical in the different browsers?

Comment 15

[José Jeria]

Build ID: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre

WFM. Compared with both IE 8 and Chrome. Note that this bug was originally comparing the performance of Mozilla with NS 4 and IE 5.5.

Comment 16

[Boris Zbarsky [:bzbarsky]]

José Jeria, I assume you tested with various cookie settings, etc?  See comment 12.

Comment 17

[José Jeria]

(In reply to comment #16)
> I assume you tested with various cookie settings, etc?  See comment
> 12.

No sorry.

Comment 18

[Worcester12345]

Brian, have you tried testing with the latest version of Firefox?

Comment 19

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Comment 20

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

I'm not seeing any slowness on those testcases. Given there has been a lot of code changes and performance improvements on Gecko since the bug was reported, I am going to close this. Please open a new bug when you encounter a related issue; attaching a profile is always a huge help. Thank you.