Closed Bug 120553 Opened 23 years ago Closed 14 years ago

scripting speed is slow (6 times slower than IE)

Categories

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

x86
Windows 2000
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: perf, testcase)

Attachments

(4 files)

I made a small page: http://gemal.dk/mozilla/strictwarn-no.html that calls a function 20 times. The total time viewing it with Mozilla (20020116) is around 2.700 millisecs Viewing it with IE6 total time is around 430 millisecs That's a factor 6 faster in IE6 than Mozilla. I have Strict JavaScript Warnings off and the JavaScript Console closed so that they're not intefering with the timings.
related/dup: bug 118933, bug 120363
Henrik, please don't file bugs badly:L 1. Cc: more people in general. 2. When claiming a bug is in the JS engine, reduce the testcase to include no DOM references, and to work in a standalone .js file that you run in the optimized JS shell (built by 'make BUILD_OPT=1 -f Makefile.ref' in js/src if on Linux, see js.mak for Windows standalone build). I get 27ms as the reported time using the soon to be attached testcase in the js shell on my 1GHz thinkpad. Reassigning to jst, possibly a window resolve or security check regression? /be
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
Setting default QA -
QA Contact: pschwartau → desale
Severity = LOW [No Crash, No severe functional failure, No Cosmetic failure] Visibility = MEDIUM [Dont see any real world website usage, Gets one point of compatibility with other browsers since it works better on IE. ] Priority = Visibility * Severity Priority = p4 adding word "qawanted" because I'm setting this priority on available data & if someone feels otherwise then please investigate this more & feel free to change this priority.
Keywords: qawanted
Priority: -- → P4
On my computer (1.4 ghz, WinME, Moz 8-8 trunk), Mozilla is faster.
Keywords: perf
desale, can you verify that the performance is better now than when this bug was filed? Can you compare it to IE and 4.x on the same hardware and OS? Thanks, /be
I will do that. Will post results once I'm done.
The Testcase reported by reporter Does not work with NS 4.x because of use of "in" in branching statement if ("findDialog" in window || document) Hence I changed code by replacing line if ("findDialog" in window || document) with if ( ("findDialog"==window) || ("findDialog" == document)) But these two testcases give me totally different results. I'm attaching testcase I created. I ran testcase I created & also I ran testcase provided by reporter. I performed tests on todays trunk (2002-09-04-08), IE, NS 4.7, NS 7.0 RTM The testresults are following. TEST RESULTS: TRUNK IE NS4.7 NS7.0RTM Reporters Testcase 343 ms 484 ms No Results 359 ms Testcase I attached 1766 ms 469 ms 1047 ms 610 ms
To run in 4.x, instead of if ("findDialog" in window || document) you want if (typeof window.findDialog != "undefined" || typeof document.findDialog != "undefined") /be
Oh Got it. I will retest it then again.
Attached file Modified Testcase (deleted) —
Modified testcase again. As Brendan suggested, I changed code by replacing line if ("findDialog" in window || document) with if (typeof window.findDialog != "undefined" || typeof document.findDialog != "undefined") So it will work with 4.x too I'm getting better results but still different than reporters testcase. I'm attaching testcase I created. I ran testcase I created. I performed test on todays trunk (2002-09-04-08), IE, NS 4.7, NS 7.0 RTM The testresults are following. TEST RESULTS: TRUNK IE NS4.7 NS7.0RTM 2nd Testcase I attached 859 ms 547 ms 657 ms 891 ms
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Using the last 2 testcases (id=97854 and id=97849) Mozilla (Build ID: 2003042008) is about as fast as IE6(SP1) on my Athlon XP1800+ with Win98 (Total is 110ms in 7 out of 10 test runs). Unfortunately the reporter's test URL is broken.
On the second testcase, once I made it a bit longer to get decent data, I see the following: 1208 total hits. Of these: 1170 under js_Execute. Of these: 175 under XPC_WN_Helper_GetProperty 631 under XPC_WN_Helper_NewResolve 104 under XPC_WN_ModsAllowed_Proto_Resolve A good chunk of the time involved is in the security manager (1/6 of the total time), XPConnect's FindMember, etc. I'll attach the profile in case someone can tell what else time is spent on.
Attached file Profile (deleted) —
dbradley has a patch to speed up FindMember I believe
I see about a 10% overall decrease with the FindMember patch. I'll have to do a debug build and see what the cache stats look like when running this test. Might be able to get some better performance by adjusting them.
Keywords: testcase
Keywords: qawanted
Assignee: general → nobody
QA Contact: desale → general
I'm on Windows XP. Results for the second testcase: Latest nightly () = In total it took 102 milliseconds. IE8 = In total it took 140 milliseconds. Google Chrome 8.0.552.237 = In total it took 604 milliseconds. These are not the result of the first run. Reloading Firefox didn't make much difference. IE8 got a little faster in general and GC8 got slower. So I think this bug can be resolved fixed/worksforme.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Blocks: 467263
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: