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, 段垚 <[email protected]> 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, 段垚 <[email protected]> wrote: > >> 在 2016/9/28 22:59, Danielle McLean 写道: >> >> From: 段垚 (mailto:[email protected]) >>> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- - Oli Olivier Lalonde http://www.syskall.com <-- connect with me!
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
