Closed Bug 1688534 Opened 3 years ago Closed 3 years ago

Optimize object literal instantiation

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

RESOLVED FIXED
87 Branch
Tracking Status
firefox87 --- fixed

People

(Reporter: arai, Assigned: arai)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

https://searchfox.org/mozilla-central/rev/7431701c98da9218fda314a54efa1a3093760f65/js/src/frontend/ObjLiteral.cpp#59-95

InterpretObjLiteralObj builds key/value array and then calls NewPlainObjectWithProperties.

there:

  • we should be able to pre-calculate the number of properties [1]
  • we don't have to build an array, if we inline AddPlainObjectProperties there [2]
  • js::NativeDefineProperty checks object type each time, but it's always plain object [3]
  • we should be able to check if there's duplicate property during compilation, and if there's not, we don't have to lookup the property before add [4]
  • there's no accessor. it's always data property [5]

[1] https://searchfox.org/mozilla-central/rev/7431701c98da9218fda314a54efa1a3093760f65/js/src/vm/ObjectGroup.cpp#307
[2] https://searchfox.org/mozilla-central/rev/7431701c98da9218fda314a54efa1a3093760f65/js/src/vm/ObjectGroup.cpp#286-301
[3] https://searchfox.org/mozilla-central/rev/7431701c98da9218fda314a54efa1a3093760f65/js/src/vm/NativeObject.cpp#1535-1592
[4] https://searchfox.org/mozilla-central/rev/7431701c98da9218fda314a54efa1a3093760f65/js/src/vm/NativeObject.cpp#1594-1620
[5] https://searchfox.org/mozilla-central/rev/7431701c98da9218fda314a54efa1a3093760f65/js/src/vm/NativeObject.cpp#1308-1310

While instantiating yahoo-mail's JS after off-thread decoding, 13% of the ScriptDecodeTask::parse (or 17% of frontend::instantiteStencils) is taken by js::InterpretObjLiteral.

(In reply to Tooru Fujisawa [:arai] from comment #0)

  • we don't have to build an array, if we inline AddPlainObjectProperties there [2]

Nice. I think the array was there for TI reasons, to get the right group, but that code has been removed.

  • we should be able to check if there's duplicate property during compilation, and if there's not, we don't have to lookup the property before add [4]
  • there's no accessor. it's always data property [5]

Maybe you can use NativeObject::addEnumerableDataProperty? That has a fast path for "single child shape already exists in the property tree", I don't know how common that is for object literals but it doesn't seem unlikely for object literals to have a similar structure.

(In reply to Jan de Mooij [:jandem] from comment #2)

Maybe you can use NativeObject::addEnumerableDataProperty? That has a fast path for "single child shape already exists in the property tree", I don't know how common that is for object literals but it doesn't seem unlikely for object literals to have a similar structure.

That is called by AddDataPropertyNonDelegate. Maybe that's a nice one to use because we know object literals aren't delegates (= prototype of another object)...

mildly depends on bug 1687428, for duplicate field part.

(In reply to Jan de Mooij [:jandem] from comment #3)

(In reply to Jan de Mooij [:jandem] from comment #2)

Maybe you can use NativeObject::addEnumerableDataProperty? That has a fast path for "single child shape already exists in the property tree", I don't know how common that is for object literals but it doesn't seem unlikely for object literals to have a similar structure.

That is called by AddDataPropertyNonDelegate. Maybe that's a nice one to use because we know object literals aren't delegates (= prototype of another object)...

Thanks!

Depends on: 1687428
Assignee: nobody → arai.unmht
Status: NEW → ASSIGNED

These flags are used in the next patch.

Depends on D103551

Attachment #9200205 - Attachment description: Bug 1688534 - Part 3: Add HasIndex and HasDuplicatePropName flags. → Bug 1688534 - Part 3: Add HasIndexOrDuplicatePropName flags.

on raptor tp6 yahoo-mail, 3% improvement (most frequent score doesn't change, but the frequency of bad score reduces).
also, 99% of the object literal hits the optimized case (no index property, no duplicate properties).

tested using BloomFilter instead of HashSet, to detect property duplication.

storage optimized case missed optimizable case
HashSet 98.99% -
BloomFilter<12> 98.97% 0.02%
BloomFilter<11> 98.93% 0.06%
BloomFilter<10> 98.86% 0.13%
BloomFilter<9> 98.72% 0.27%
BloomFilter<8> 98.34% 0.66%
BloomFilter<7> 97.43% 1.58%
BloomFilter<6> 96.06% 2.96%

also I don't see notable difference in the parse mark result, for any case (with HashMap, with BloomFilter, without duplication detection)

reverted to use HashSet, and filed bug 1690274 for bloom filter.

See Also: → 1690274
Pushed by arai_a@mac.com:
https://hg.mozilla.org/integration/autoland/rev/9c82c4f218ee
Part 1: Store the number of properties/elements in ObjLiteralStencil. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/ae4890a14011
Part 2: Inline NewPlainObjectWithProperties to avoid building properties vector. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/50f5c8ec9472
Part 3: Add HasIndexOrDuplicatePropName flags. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/2ce5fee4f1b3
Part 4: Add fast path for object literal without index or duplicate properties. r=tcampbell
Pushed by arai_a@mac.com:
https://hg.mozilla.org/integration/autoland/rev/7acd2b3e2e5a
Part 1: Store the number of properties/elements in ObjLiteralStencil. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/118670433729
Part 2: Inline NewPlainObjectWithProperties to avoid building properties vector. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/9e40a25189e8
Part 3: Add HasIndexOrDuplicatePropName flags. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/0e1735c489aa
Part 4: Add fast path for object literal without index or duplicate properties. r=tcampbell
Flags: needinfo?(arai.unmht)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: