-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
doc: add ReflectConstruct to known perf issues #50111
doc: add ReflectConstruct to known perf issues #50111
Conversation
Review requested:
|
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.
FWIW the reason isn't ReflectConstruct per-se it's the usage of anonymous (new) classes each time with it that is the problem. Still I generally agree there be very little cases where it is required.
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.
Yeah I'm not sure it makes sense to list it here, because using Reflect.construct
would not be more performant. The list (currently) lists the primordials
for which it's faster to call the non-primordial version (e.g., rewriting someArray.push(1)
to ArrayPrototypePush(someArray, 1)
can lead to a huge perf regression in hot path). I think it makes more sense to either have it as a separate list, or maybe even a different document since it's hardly related to primordials IIUC.
Maybe: Primordials we should avoid for performance issuesBelow are some primordials that we can avoid to be more performant:
In general, it's not a problem if you don't have an alternative but sometimes you can avoid it by writing the code in a different way and have less overhead. |
Have measured if
Otherwise it seems not far-fetched this think the reader might conclude that |
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.
lgtm
I agree with @aduh95 's comments. We should avoid Reflect.construct as well - otherwise people might see this and use Reflect.construct instead of ReflectConstruct which isn't the point (which is - they should avoid creating new types of classes inside a function instead of having a shared class like in those issues) |
Any recommendations on where I should put this recommendation? Should I write something like #50111 (comment) or close this PR? |
Co-authored-by: Uzlopak <[email protected]>
Co-authored-by: Antoine du Hamel <[email protected]>
@@ -124,7 +124,7 @@ performance of code in Node.js. | |||
* `SafePromisePrototypeFinally`: use `try {} finally {}` block instead. | |||
* `ReflectConstruct`: Also affects `Reflect.construct`. | |||
`ReflectConstruct` creates new types of classes inside functions. |
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.
I know I am nitpicking myself.
Maybe should be "at runtime" and not "inside functions".
Sorry.
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.
What about:
ReflectConstruct
instantiates a class with a custom constructor.
Landed in 340b9a8 |
PR-URL: #50111 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Matteo Collina <[email protected]>
PR-URL: nodejs#50111 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Matteo Collina <[email protected]>
PR-URL: #50111 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Matteo Collina <[email protected]>
There are a lot of PRs created initially by nodejs/performance#109 to improve performance issues with this primordial.