在 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] <mailto:[email protected]>> wrote:

    在 2016/9/28 22:59, Danielle McLean 写道:

        From: 段垚 (mailto:[email protected] <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] <mailto:[email protected]>
    https://mail.mozilla.org/listinfo/es-discuss
    <https://mail.mozilla.org/listinfo/es-discuss>



_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to