Why is Object.create so much slower than a constructor?

后端 未结 4 1601
南旧
南旧 2021-02-07 12:00

Background

In a project I\'m maintaining we make extensive use of null prototype objects as a poor man\'s alternative to (string key only) Maps, which are not natively

4条回答
  •  日久生厌
    2021-02-07 12:34

    In a strive to improve performance, I wrote a test, and found that the native Object.create approach unexpectedly performs much slower than the method involving an extra constructor with an ad hoc prototype, in all browsers

    I was ingenuously expecting the latter method to be slower as it involves invoking a user defined constructor, which doesn't happen in the former case.

    Your reasoning postulates that the new operator and Object.create have to use the same inner "object creation" code, with an extra call to the custom constructor for new. That's why you find the test result surprising, because you think you're comparing A+B with A.

    But that's not true, you shouldn't assume that much about the implementations of new and Object.create. Both can resolve to different JS or "native" (mostly C++) and your custom constructor can easily be optimized away by the parser.

    Beside curiosity, as others have well explained, the empty object creation is a bad focus point for optimizing the entire application - unless you've got some full scale profiling data proving otherwise.

    If you're really worried about objet creation time, add a counter for the number of objects created, increment it in your Empty constructor, log the number of objects created in the lifetime of the program, multiply by the slowest browser execution time, and see (most probably) how negligible creation time is.

提交回复
热议问题