(In reply to Jan de Mooij [:jandem] from comment #1) > Worth noting that the WebKit motivation [was mostly performance](https://github.com/WebKit/WebKit/commit/997e074bb35ed07b69c9b821141c91dd548e0d02): > > We mostly want it because web tooling benchamrk uses it in the hot path of the chai-wtb test, where having native Error.captureStackTrace is a 5% progression over the polyfill. > > According to that commit message, they diverge from V8 by making this a data property instead of an accessor. Bug 1740472 has some background on this. I wish they had followed V8 here instead of adding another potential web compat problem. It's worth noting that there's no evidence this is a real-world performance improvement - the JetStream test in question is a test runner typically used in CI / server side environments so we should expect no performance improvement for real world users or content. It would have been much simpler to update the benchmark to drop the usage of the API, or the polyfill, than to ship an unspecified API to the web to improve the subtest score.
Bug 1886820 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jan de Mooij [:jandem] from comment #1) > Worth noting that the WebKit motivation [was mostly performance](https://github.com/WebKit/WebKit/commit/997e074bb35ed07b69c9b821141c91dd548e0d02): > > We mostly want it because web tooling benchamrk uses it in the hot path of the chai-wtb test, where having native Error.captureStackTrace is a 5% progression over the polyfill. > > According to that commit message, they diverge from V8 by making this a data property instead of an accessor. Bug 1740472 has some background on this. I wish they had followed V8 here instead of adding another potential web compat problem. Also worth noting that there's no evidence this is a real-world performance improvement - the JetStream test in question is a test runner typically used in CI / server side environments so we should expect no performance improvement for real world users or content. It would have been much simpler to update the benchmark to drop the usage of the API, or the polyfill, than to ship an unspecified API to the web to improve the subtest score.