108984 - very bad performance while expanding the "table of contents" tree on the left side (long document.cookie manipulations are slow)

Status: RESOLVED INCOMPLETE

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

Description

[lchiang]

Goto URL and after the page loads try to expand the item "Top-Level Properties
and Functions"  int the "Client-Side JavaScript Reference v1.3" table of
contents (on the left) using:

Netscape6.2                 -> SLOWEST!!! (looks like a hang, dissapointing)
Mozilla0.9.4                -> slow
Mozilla (trunk of 11.5.01)  -> still slow but a little bit better
IE5.5                       -> fast (almost spontaentous)
Please check this issue and reassign the bug to the proper developer.



------- Additional Comments From [e-mail] 2001-11-07 17:15:40 ----

What is the machine speed you are using?
I'm going to move this bug to bugzilla.  There isn't anything proprietary on
this bug report.



------- Bug moved to this database by [e-mail] 2001-11-07 17:18 -------

This bug previously known as bug 10870 at http://bugscape.netscape.com/
http://bugscape.netscape.com/show_bug.cgi?id=10870
Originally filed under the Browser product and Browser-General component.

Comment 1

[lchiang]

John or Jason, can you see where the bad performance may be in and reassign?

Comment 2

[John Morrison]

I did a Quantify run, measuring the task of opening '3 Event Handlers' when
just opened to the TOC page itself: 
  http://developer.netscape.com/docs/manuals/js/client/jsref/toc.htm

64% of the time was spent in nsWindowSH::GetProperty, 99+% calling into 
doCheckReadAccess.

I reverted rev 1.74 of dom/src/base/nsDOMClassInfo.cpp, where the security
fix for bug 105705 was made.

  Opening '3 Event Handlers' (win2k):
    rev 1.74:  ~31 sec.
    rev 1.73:   ~8 sec.

So, that's a lot of the problem. Not sure where the rest of it lies.

However, one really strange thing ... I set up a mirror copy of the TOC page
at http://jrgm/bugs/108984/toc.html (all the scripts are inline to the page,
and otherwise there are three tiny GIF files). This should behave no
differently than the other document. But, that page opens the twisty in

    rev 1.74 on jrgm.mcom.com:  ~1.8 sec.
    rev 1.73 on jrgm.mcom.com:  ~0.8 sec.

How can that be? What am I missing here. (And, no, there is no network traffic
during this script execution; it is 100% CPU bound).

Comment 3

[John Morrison]

bug in bugzilla?; resetting to NEW

Comment 4

[Johnny Stenback (:jst)]

The speed difference between the two copies of the test sounds really really
strange. I'll have to point Quantify at both cases and see what the difference is.

Comment 5

[John Morrison]

The root cause of the speed difference between the two servers is that the JS
that implements that tree is doing an inefficient string compare on the 
document.cookie string. Since jrgm.mcom.com isn't (typically) serving any
cookies, then that string is short; however .netscape.com dishes a lot of 
cookies, and the string is much longer, so the inefficiency, especially coupled
with the slower property access (security change) makes this blow up.

I may have more later, but the property lookup is the main thing that mozilla
can fix (and maybe someone with evangelism can fixup that script to not try 
to do a "pointer walk" of a string in javascript :-}

Comment 6

[Johnny Stenback (:jst)]

This should be sped up by alot soon once Mitch's security check optimization
lands, probably sometime next week.

Comment 7

[Johnny Stenback (:jst)]

The security check optimization is checked in, but we're still slow...

Comment 8

[Brendan Eich [:brendan]]

jprof time?  Or quick-n-dirty test-hack time?  I.e., are we slow just cuz of the
assignments to document.cookie, or if you eliminate those, are we still slow?

/be

Comment 9

[Daniel Bratell]

I just tested this and it was as fast in Mozilla as in MSIE (give or take a
couple of tenths of a second). Is this because of server changes or is this
fixed in Mozilla? Anyway, I'm pretty sure this is a dupe/dependant on some other
DOM/JavaScript/Security performace bug.

Comment 10

[John Morrison]

Due to the implementation of that "tree", the performance is a function of 
the number of '.netscape.com' cookies that you have. For a clean profile, I 
can toggle the '3. Event Handlers' twisty in about 1 sec on 500MHz/128MB/win2k,
but with my normal profile (admittedly weighed down by a few job-related 
cookies that a typical web user would have), it takes about 8 seconds to 
toggle the twisty.

So that's a lot faster than it was (comment #2 above), although it's still not
zippy. 

Part of the slowness, for this particular example, can be addressed by 
rewriting that 3.0-era 'tree' to be a little more efficient (although it ran 
quite quickly in Nav3.0). cc: aruner if TEDS want to take this on, I'll 
point out a couple of things that could be better.

I still think that there is room for improvement in mozilla code, although I'm
not sure what priority this should have.

p.s., if you want to see the effect of many cookies for .netscape.com, just 
shutdown and edit cookies.txt to add 20 lines of (tab separated fields):

.netscape.com	TRUE	/	FALSE	1293839890	foobar1	baz

with foobar1, being incremented to foobar2, foobar3 on each line.

Comment 11

[Johnny Stenback (:jst)]

Pushing to mozilla1.0

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

nsbeta1-

Before you renominate, please query bugs marked nsbeta1+ keyword with [ADT# RTM]
in status whiteboard (where # is a number between 1 and 3) and make sure that
this bug is at least as important as those.

Comment 13

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 14

[Fabian Guisset]

URL doesn't show the problem anymore, adding info to summary. Basically this bug
states that document.cookie manipulations are very slow if there are lots of
cookies stored. Anything we can do about it?

Comment 15

[Boris Zbarsky [:bzbarsky]]

The cookie backend has gotten pretty significantly changed since 2001... is
there still an issue here?

Comment 16

[Wayne Mery (:wsmwk)]

URL no longer exists.