Closed Bug 169531 Opened 22 years ago Closed 16 years ago

Creating new objects in Mozilla is sometimes even 5 times slower than in IE

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: zbraniecki, Unassigned)

References

Details

(Keywords: perf)

Attachments

(4 files)

HTML test - using object constructors; all variables declared locally
1.96 KB, text/html
Details
HTML test - using object literals; all variables declared locally
1.81 KB, text/html
Details
JS shell test - using object constructors; all variables declared locally
1.17 KB, text/plain
Details
JS shell test - using object literals; all variables declared locally
1.03 KB, text/plain
Details 
On my machine (Athlon 750, Win2k) Mozilla was slower than IE, Opera and NS4 in
creating Objects.
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?
Assignee: rogerl → khanson
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!!!
Blocks: 117611
Keywords: perf
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
Blocks: 21762
Depends on: 123668
Assignee: khanson → general
QA Contact: pschwartau → general
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
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
(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?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: