Closed
Bug 1131099
Opened 10 years ago
Closed 10 years ago
There is still a performance problem with Object.create(null)
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla39
People
(Reporter: evilpies, Assigned: jandem)
References
()
Details
Attachments
(2 files)
5.98 KB,
patch
|
bhackett1024
:
review+
|
Details | Diff | Splinter Review |
70.44 KB,
application/x-bzip
|
Details |
John says this is related to property accesses performance, but I haven't looked at it. We are the only browser where Object.create(null) is slower.
Assignee | ||
Comment 2•10 years ago
|
||
Problem was that TemporaryTypeSet::getCommonPrototype returned nullptr if (1) it couldn't determine the proto and (2) if there was no proto (the Object.create(null) case). TypeCanHaveExtraIndexedProperties then returned true and IonBuilder deoptimized an element access.
This patch makes getCommonPrototype return a bool and adds a proto outparam, so that we can distinguish those two cases.
Numbers (before/after/d8) for a shell version:
Without Object.create: 659 / 658 / 1120
With Object.create: 1986 / 695 / 1032
underscore: 34131 / 33996 / 2916
Note that Object.create is still a bit slower but the difference is a *lot* smaller. Also, underscore is extremely slow, will investigate this more.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Flags: needinfo?(jdemooij)
Attachment #8561546 -
Flags: review?(bhackett1024)
Assignee | ||
Comment 3•10 years ago
|
||
Some other things to investigate:
(1) The GetElementIC we used without this patch kept bailing instead of using a dense-element stub.
(2) We still spend a lot of time in GetProperty/CallProperty VM functions.
Flags: needinfo?(jdemooij)
Updated•10 years ago
|
Attachment #8561546 -
Flags: review?(bhackett1024) → review+
Assignee | ||
Comment 4•10 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #2)
> Also, underscore is extremely slow, will investigate this more.
Filed bug 1131537, bug 1131538.
(In reply to Jan de Mooij [:jandem] from comment #3)
> (1) The GetElementIC we used without this patch kept bailing instead of
> using a dense-element stub.
Filed bug 1131531.
> (2) We still spend a lot of time in GetProperty/CallProperty VM functions.
Filed bug 1131523.
Assignee | ||
Comment 5•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/5d69960fc738
Keeping the needinfo; I want to find out why we're still a little slower with Object.create.
Keywords: leave-open
Seems like this has found a lot of interesting performance problems, could we add something to awfy to track these?
Comment 7•10 years ago
|
||
Assignee | ||
Comment 8•10 years ago
|
||
Updated•10 years ago
|
Flags: needinfo?(hv1989)
Comment 9•10 years ago
|
||
(In reply to Tom Schuster [:evilpie] from comment #6)
> Seems like this has found a lot of interesting performance problems, could
> we add something to awfy to track these?
https://github.com/h4writer/arewefastyet/commit/45ca26e8145eb6928f6f685105ba15b8781e28bd
Flags: needinfo?(hv1989)
Assignee | ||
Comment 10•10 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #5)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/5d69960fc738
>
> Keeping the needinfo; I want to find out why we're still a little slower
> with Object.create.
Actually I'll just call this fixed, the difference is very small now so it's not worth spending a lot of time on. If you have a test where Object.create(null) is still a lot slower than {} please file a new bug.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(jdemooij)
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in
before you can comment on or make changes to this bug.
Description
•