Status: New
Owner: ----
New issue 3649 by [email protected]: No way to quickly make
non-enumerable instance properties
https://code.google.com/p/v8/issues/detail?id=3649
Currently the cost of creating objects who have instance level
non-enumerable properties is prohibitive.
Why is this important?
Often users will JSON.stringify/extend/merge/copy or use some sort of
enumerating function (like deepEqual when comparing) on objects.
Unfortunately some data, should not be made available to such methods.
Examples could be, internal framework meta-data, state, objects known to
contain cycles.
As far as I can tell there are 4 ways to accomplish this non enumerable
state:
Marking string properties as non-enumerable
Using symbols
Using a WeakMap to store the state off-object
Unfortunately all of these appear to have downsides.
Non-enumerable string properties: calling defineProperty is prohibitively
slow
Symbols: faster to create than defProp, but slower for setting and slower
for accessing than regular properties
WeakMaps: under heavy use crash V8 (other issue already opened) and
lookups/sets are slower than regular properties
Some related evil micro-benchmarks:
cost of marking an instance property as non-enumerable
new Obj + enumerable property: baseline
new Obj + non-enumerable property (via def prop): 76x slower
new Obj + non-enumerable property (via Symbol): 5.2x slower
http://jsperf.com/symbol-vs-prop-vs-def-prop/3
cost of accessing such a property (symbol is unfortunately slower)
Enumerable string: obj['foo'] === 1: baseline
Non-enumerable string: obj['defined'] === 1: same as basline
Symbol: obj[FOO] === 1: 7x slower
http://jsperf.com/symbol-vs-property/2
note: WeakMap was removed, as it crashed chrome.
Conclusion
We have considered moving to symbols. This gave 10%-20% improved initial
render cost vs. non-enumerable (string) properties. The downside is that
symbols results in much slower access framework wide. The trade-off is
still a win, but it is an unfortunate trade-off to make.
Ideally we would like something with "encapsulation" at least as strong as
non-enumerable string properties, but with the performance of enumerable
properties. So, this bug is asking to improve one of symbols,
non-enumerable string properties, or weak maps to be as fast as enumerable
properties.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
