lchiang
	Description • 23 years ago

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 lchiang@netscape.com 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 lchiang@netscape.com 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.

	lchiang
	Comment 1 • 23 years ago

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

	John Morrison
	Comment 2 • 23 years ago

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).

	John Morrison
	Comment 3 • 23 years ago

bug in bugzilla?; resetting to NEW

	Johnny Stenback (:jst)
	Comment 4 • 23 years ago

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.

	John Morrison
	Comment 5 • 23 years ago

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 :-}

	Johnny Stenback (:jst)
	Comment 6 • 23 years ago

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

	Johnny Stenback (:jst)
	Comment 7 • 23 years ago

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

	Brendan Eich [:brendan]
	Comment 8 • 23 years ago

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

	Daniel Bratell
	Comment 9 • 23 years ago

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.

	John Morrison
	Comment 10 • 23 years ago

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.

	Johnny Stenback (:jst)
	Comment 11 • 23 years ago

Pushing to mozilla1.0

	Heikki Toivonen (remove -bugzilla when emailing directly)
	Comment 12 • 23 years ago

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.

	Johnny Stenback (:jst)
	Comment 13 • 22 years ago

Mass-reassigning bugs to dom_bugs@netscape.com

	Fabian Guisset
	Comment 14 • 21 years ago

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?

	Boris Zbarsky [:bzbarsky]
	Comment 15 • 20 years ago

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

	Wayne Mery (:wsmwk)
	Comment 16 • 16 years ago

URL no longer exists.