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)
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
Comment 2•23 years ago
|
||
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
Comment 3•23 years ago
|
||
Updated•23 years ago
|
Component: Javascript Engine → DOM Level 0
Comment 5•23 years ago
|
||
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
Comment 6•22 years ago
|
||
On my computer (1.4 ghz, WinME, Moz 8-8 trunk), Mozilla is faster.
Comment 7•22 years ago
|
||
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
Comment 8•22 years ago
|
||
I will do that. Will post results once I'm done.
Comment 9•22 years ago
|
||
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
Comment 10•22 years ago
|
||
To run in 4.x, instead of
if ("findDialog" in window || document)
you want
if (typeof window.findDialog != "undefined" ||
typeof document.findDialog != "undefined")
/be
Comment 11•22 years ago
|
||
Oh Got it.
I will retest it then again.
Comment 12•22 years ago
|
||
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
Comment 14•22 years ago
|
||
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.
Comment 15•21 years ago
|
||
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.
Comment 16•21 years ago
|
||
Comment 17•21 years ago
|
||
dbradley has a patch to speed up FindMember I believe
Comment 18•21 years ago
|
||
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.
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: desale → general
Comment 19•14 years ago
|
||
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.
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•