On my machine (Athlon 750, Win2k) Mozilla was slower than IE, Opera and NS4 in creating Objects.

http://alladyn.art.pl/MozillaObjects/

IE6: Creating empty object: 40 Creating object with one property: 90 Creating object with 3 properties: 121 Creating Number Object: 50 Creating String Object: 100 Creating RegExp Object: 130 Creating Array Object: 50 Mozilla 1.2 trunk (20020909) Creating empty object: 170 Creating object with one property: 391 Creating object with 3 properties: 440 Creating Number Object: 351 Creating String Object: 310 Creating RegExp Object: 431 Creating Array Object: 430

NS4.8: Creating empty object: 230 Creating object with one property: 291 Creating object with 3 properties: 390 Creating Number Object: 241 Creating String Object: 230 Creating RegExp Object: 301 Creating Array Object: 320 Opera 6.03: Creating empty object: 90 Creating object with one property: 170 Creating object with 3 properties: 230 Creating Number Object: 191 Creating String Object: 250 Creating RegExp Object: 981 Creating Array Object: 161

After Mazie's Comment in Bug #169442 i checked how it works locally: http://alladyn.art.pl/gandalf/MozillaObjects/index2.html IE6: Creating empty object: 311 Mozilla 1.2 trunk(20020909) : Creating empty object: 5328 I cannot explain this...

Reassigning to Kenton; cc'ing Mazie - Zbigniew, thank you for these tests! However, when I try to go to the first URL you have, in Comment #1, I get "Not Found": http://alladyn.art.pl/MozillaObjects/ Has the URL for the first test changed?

Ouch! Very sorry. http://alladyn.art.pl/gandalf/MozillaObjects/ I think that if we want to make Moz 1.2 faster, we should work with small problems, like this one or #169442 . I have few more from my friends, should i set Kenton as the Owner, and CC Mazie by myself next time? :)

> I have few more from my friends, should I set Kenton as the Owner, > and CC Mazie by myself next time? :) Zbigniew: thanks, that would be great! You are right, each issue should have its own separate bug. Furthermore, there is a meta bug for JavaScript Engine performance, also: bug 117611 [META] JS Engine Performance Issues Each separate bug, after it is filed, should be added as a "dependency" to this bug. To do this, go to bug 117611 and look for the phrase "Bug 117611 depends on: ". Then you can add the new performance bug number to the textbox, and hit "Commit". --- You raise a good question about the performance problems involving global variable access in the browser. This is because the Mozilla DOM does a security check every time a global variable is accessed (to guard against malicious code). IE does not do this, so IE is faster on global variable access (but less safe!). Any bug report concerning that issue should be filed against the DOM Level 0 component, not JavaScript Engine. The meta bug above is only for performance questions in the standalone JS Engine, not for DOM issues. Note there is a separate meta bug for the DOM: bug 21762 tracking: poor performance using DHTML Thanks for your help!!!

could upcoming fix for bug 123668 help ?

cc'ing brendan

I'm not sure if bug 123668 is related. Here we have big problems with different types of Objects. If new Object is only 4,5 times slower, new Array is 9 times slower!!! I think that we should wait for the patch in bug 123668 and see if it'll change anything here, but investigate this separatly.

I have edited the tests of Zbigniew Braniecki and tested them in the following browsers and shells. The variables are set locally to avoid DOM security checks. System: Windows 2000, Memory 256 MB, Processor: 1.7 GHz I am using trunk and branch builds of Mozilla from 2002091808. The XPCshells are from the same date. Testing object constructors in the browsers: IE6 Moz Trunk Moz Branch Array 32 ms 156 m 141 ms Object 31 ms 125 ms 109 ms RegExp 78 ms 250 ms 219 ms String 78 ms 172 ms 156 ms Date 63 ms 203 ms 188 ms Function 265 ms 516 ms 500 ms Number 32 ms 203 ms 188 ms Testing object constructors in the shell: Optimized JS Shell XPCshell Trunk XPCshell Branch Array 47 ms 109 ms 94 ms Object 15 ms 78 ms 62 ms RegExp 47 ms 125 ms 453 ms String 31 ms 94 ms 94 ms Date 16 ms 125 ms 94 ms Function 219 ms 625 ms 312 ms Number 46 ms 109 ms 110 ms Testing object literals in the browsers: IE6 Moz Trunk Moz Branch Array 15 ms 203 ms 156 ms Object 32 ms 125 ms 125 ms RegExp 31 ms 47 ms 31 ms String 0 ms 0 ms 0 ms Date n/a n/a n/a Function 31 ms 141 ms 109 ms Number 0 ms 0 ms 0 ms Testing object literals in the shell: Optimized JS Shell XPCshell Trunk XPCshell Branch Array 32 ms 78 ms 78 ms Object 31 ms 78 ms 78 ms RegExp 0 ms 0 ms 0 ms String 0 ms 0 ms 0 ms Date n/a n/a n/a Function 16 ms 63 ms 78 ms Number 0 ms 0 ms 15 ms

If mazie's numbers are from the same machine, then the JS shell beats IE6 for all but Array creation, and oddly, Number instances. Phil, a couple of thoughts: 1. Can we make this bug a meta-bug and track another non-meta bug for speeding up Array creation time? 2. Is the Number time reproducible? 3. Why is Mozilla so much slower than the JS shell? The xpcshell is slower, suggesting JS_THREADSAFE is partly to blame (it enables GC locking code that hasn't been optimized for the uncontested lock case). But Mozilla is slower still, and I don't know why. The GC may be running more. We could control for that, but it's still a head-to-head battle loss against IE. With some more investigation of where the cycles are going (jprof might help), this could be split out into another bug tracked from here. /be

Also, please try the patch from bug 123668 and report results, when you get a chance. Thanks! /be

mazie, can you use the technique (that doesn't include the missing var statements, only the conditional definition of WScript and the ellapsed time calculated *before* before the call to the print function) from http://bugzilla.mozilla.org/attachment.cgi?id=100277&action=view to test cscript [/noscript] too? comparing a shell to a web browser isn't fair especially when there's an equivalent shell available...

Current status: Mazie is trying to run performance tests in all the various shells: the JS shell with and without the patch from bug 123668, the XPCshell, and the CScript shell as timeless suggested above. However, she is running into an intermittent crash with the patch for bug 123668 applied. She will post details in that bug -

With Brendan's patch for bug 123668, I no longer crash. (http://bugzilla.mozilla.org/show_bug.cgi?id=123668#c31) I have also made CScript tests as timeless suggested. I will attach these below.

Actually, let me refer users to the JS, and CScript tests attached to bug 123668. I had to increase the number of interations to 10^6, not 10^4 as in the above tests, for greater resolution in the timing results. Here are my results with CScript, the optimized JS shell before and after the patch, and the XPCshell from today's Mozilla trunk build (2002092508): Number of iterations: 10^6 System: Windows 2000, Memory 256 MB, Processor: 1.7 GHz CScript: Microsoft (R) Windows Script Host Version 5.6 Testing constructors: CScript Opt JS(w/o patch) Opt JS(w/patch) Trunk XPCshell Array: 2578 ms 3672 ms 2875 ms 11875 ms Object: 2578 ms 2312 ms 1594 ms 9391 ms RegExp: 8687 ms 5672 ms 4141 ms 14687 ms String: 6797 ms 2187 ms 2344 ms 10735 ms Date: 5563 ms 3141 ms 3031 ms 12578 ms Function: 18859 ms 12891 ms 10172 ms 33406 ms Number: 2672 ms 2656 ms 2640 ms 12500 ms Testing literals: CScript Opt JS(w/o patch) Opt JS(w/patch) Trunk XPCshell Array: 2437 ms 3750 ms 2969 ms 12032 ms Object: 2375 ms 2359 ms 1703 ms 9406 ms RegExp: 2656 ms 406 ms 422 ms 312 ms String: 532 ms 406 ms 406 ms 313 ms Date: n/a n/a n/a n/a Function: 3296 ms 1954 ms 1250 ms 9641 ms Number: 422 ms 390 ms 390 ms 328 ms

Mazie: thanks! Now that we have these results, we see that the JS shell with Brendan's patch for bug 123668 compares favorably to the CScript shell. In fact, the new JS shell is faster on everything except Array creation, but even in that case it is nearly the same. Brendan: with these new results, would you still like me to make this a meta-bug, and file a separate non-meta bug on Array creation?

Ok, there are two problems remaining. First, and the one the summary best describes (so the one that should be tracked here): the slowdown due to thread safety in the xpcshell numbers, compared to the js shell numbers. Second, the new Array slowness. The latter should get its own bug. It can be fixed more readily with a patch to jsarray.c only (to avoid defining a length property on each Array instance, requiring a mutable scope for each instance). I'm actually patching the thread-safety performance problem in a new patch for bug 123668, which I should be able to attach later today. /be

Brendan: thanks - I have filed bug 171262, "Performance: improve speed of new Array creation" and have made it a dependency for the overall meta-bug on JS Engine performance, bug 117611

Firefox RegExp is highly variable, probably from the arena malloc, but we have other bugs for that. Firefox 3: Array: 4 ms Object: 3 ms RegExp: 102 ms String: 8 ms Date: 40 ms Function: 33 ms Number: 3 ms IE: Array: 47 ms Object: 47 ms RegExp: 94 ms String: 31 ms Date: 16 ms Function: 62 ms Number: 32 ms

(In reply to comment #25) > Firefox RegExp is highly variable, probably from the arena malloc, but we have > other bugs for that. > > Firefox 3: > Array: 4 ms > Object: 3 ms > RegExp: 102 ms > String: 8 ms > Date: 40 ms > Function: 33 ms > Number: 3 ms > > IE: > Array: 47 ms > Object: 47 ms > RegExp: 94 ms > String: 31 ms > Date: 16 ms > Function: 62 ms > Number: 32 ms What version of IE is this with?