Proposal: add an option to omit prototype of objects created by JSON.parse()

Olivier Lalonde olalonde at gmail.com
Thu Sep 29 21:20:36 UTC 2016


Given that JSON.parse doesn't necessarily return an object, would the
noPrototype option would be ignored on e.g. `JSON.parse('"some string"')`
or `JSON.parse('true')`?

On Wed, Sep 28, 2016 at 9:46 AM, 段垚 <duanyao at ustc.edu> wrote:

> 在 2016/9/29 0:04, Michał Wadas 写道:
>
> Have you ever encountered performance issue because of copying object on
> deserialization?
>
> Not yet.
>
>
> https://gist.github.com/Ginden/381448a17f50c7669b9a3693742e3a3d For me
> results are:
>
> Simple JSON.parse, 100000 iterations: 39.594999999997526ms
> JSON.parse with copy, 100000 iterations: 184.5699999999997ms
> JSON.parse with __proto__ change, 100000 iterations: 89.75500000000102ms
>
> Thanks for writing this test. I got similar result on Firefox; while on
> Chrome and Edge, there is not much difference between coping and changing
> __proto__ .
>
> However, it is not easy to messure overhead of GC after copy and the
> effect of __proto__ change on property access performance.
>
>
>
> On Wed, Sep 28, 2016 at 5:49 PM, 段垚 <duanyao at ustc.edu> wrote:
>
>> 在 2016/9/28 22:59, Danielle McLean 写道:
>>
>> From: 段垚 (mailto:duanyao at ustc.edu)
>>> Date: 28 September 2016 at 16:36:52
>>>
>>> [I]mplementors warn that mutating prototype causes "performance
>>>> hazards".
>>>>
>>> You don't actually need to mutate any prototypes to get prototypeless
>>> objects out of `JSON.parse` - the reviver function is allowed to
>>> return a new object instead, so you can create a fresh one with the
>>> correct prototype. For example:
>>>
>>> ```js
>>> JSON.parse(string, function(k, v) {
>>>    if (v && typeof v === 'object' && !Array.isArray(v)) {
>>>      return Object.assign(Object.create(null), v);
>>>    }
>>>    return v;
>>> });
>>> ```
>>>
>>
>> Yes, but creating a copy also has performance penalty. This proposal is
>> made for performance.
>>
>> How about adding an option to omit prototype of objects created by
>>>> JSON.parse()?
>>>>
>>>> JSON.parse(str, { noPrototype: true });
>>>>
>>> While you can achieve the appropriate result already without extra
>>> language support, I think this particular situation is common enough
>>> that such an option might be a good idea.
>>>
>>> How would you expect this new parameter to interact with the existing
>>> second parameter to `JSON.parse`, the reviver function? I'd suggest
>>> that the cleanest way to add the options would be for the second
>>> parameter to be either an object or function, like this:
>>>
>>> ```js
>>> JSON.parse(str, someFunc);
>>> // equivalent to
>>> JSON.parse(str, {reviver: someFunc});
>>> ```
>>>
>> Looks reasonable.
>>
>> Maybe we can simply add another method, say `JSON.parseWithoutPrototype()`.
>> This makes feature detection easier.
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
- Oli

Olivier Lalonde
http://www.syskall.com <-- connect with me!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160929/5e720bf5/attachment.html>


More information about the es-discuss mailing list