-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib: make safe primordials safe to construct #36428
Conversation
I wonder if there's a performance impact on this? Not saying that this should be blocked if the performance degraded, just curious how big the impact would be. |
That would be indeed interesting to mesure. My guess is it would perform better with this PR (because it no longer iterates over the argument array), but maybe V8 has some optimisation shortcuts for this kind of thing. |
@nodejs/benchmarking My understanding is that benchmarking.nodejs.org is no longer updating and the Benchmarking WG is dormant and on its way to not being a thing anymore (if it hasn't already happened) but I wonder if there's a host or job that can run a good cross-set of benchmarks without taking days or weeks to run. This PR could have wide-ranging performance impacts (positive, I hope, but would like to measure). |
Note that once tc39/ecma262#2216 is implemented, it will be possible to revert this. |
@Trott From what I can tell https://benchmarking.nodejs.org/ is still updating? |
It seems that the graphs are being updated for 10.x and 12.x It doesn't look like there have ever been results recorded there for 14.x or 15.x, and master branch/nightly doesn't seem to be recorded anymore either. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To ensure the correct length
, this should use the following, which also makes it possible to remove // eslint‑disable‑line no‑useless‑constructor
comment:
I'm curious if the regressions from #36532 stem from the changes in this PR. If so, then this PR would have quite a negative performance impact.
FWIW I've been doing something like that on my own dedicated (older and spare) hardware since February. The total time to run all of the benchmarks used there is currently around 22-24 hours. I think that kind of time frame is the sweet spot for detecting (committed) performance regressions in a timely manner while covering a decent number of categories. |
Given that #36587 doesn't have any negative impact on buffer creation perf, it's probably safe to assume this PR won't have much impact either. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems OK to me, although I would love to see a benchmark out of caution. Just not sure which ones are most likely to be affected by this.
Benchmark CI (module): https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/796/
Results
|
Landed in 997f2fc...40fc395 |
PR-URL: #36428 Reviewed-By: Rich Trott <[email protected]>
Using an explicit constructor is necessary to avoid relying on `Array.prototype[Symbol.iterator]` and `%ArrayIteratorPrototype%.next`, which can be mutated by users. PR-URL: #36587 Refs: #36428 Refs: #36532 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
PR-URL: #36428 Reviewed-By: Rich Trott <[email protected]>
Using an explicit constructor is necessary to avoid relying on `Array.prototype[Symbol.iterator]` and `%ArrayIteratorPrototype%.next`, which can be mutated by users. PR-URL: #36587 Refs: #36428 Refs: #36532 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
PR-URL: #36428 Reviewed-By: Rich Trott <[email protected]>
Using an explicit constructor is necessary to avoid relying on `Array.prototype[Symbol.iterator]` and `%ArrayIteratorPrototype%.next`, which can be mutated by users. PR-URL: #36587 Refs: #36428 Refs: #36532 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
PR-URL: #36428 Reviewed-By: Rich Trott <[email protected]>
Using an explicit constructor is necessary to avoid relying on `Array.prototype[Symbol.iterator]` and `%ArrayIteratorPrototype%.next`, which can be mutated by users. PR-URL: #36587 Refs: #36428 Refs: #36532 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
PR-URL: #36428 Reviewed-By: Rich Trott <[email protected]>
Using an explicit constructor is necessary to avoid relying on `Array.prototype[Symbol.iterator]` and `%ArrayIteratorPrototype%.next`, which can be mutated by users. PR-URL: #36587 Refs: #36428 Refs: #36532 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
The current constructors of
Safe(Weak)?(Map|Set)
classes are not "safe", they executes%ArrayIteratorPrototype%.next
which may have been mutated in user-land.That's the expected behaviour of subclasses default constructor defined the ECMAScript spec, and I think it makes sense to disable this behaviour in this case.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes