Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 like this @sirenkovladd! Can you provide a little microbenchmark result. We have gone back and forth on this pattern and a microbenchmark would help solidify a path.
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.
the following optimization pattern should not affect performance. unlike in user code,
require
is inlined to the following code:(this transform is done in internal-module-registry-scanner.ts, called in
sliceSourceCode
)the first half of this is already a cache lookup, specifically a native array access into the JSInternalFieldObjectImpl in InternalModuleRegistry.h/cpp. this lookup should be incredibly instant and very JIT friendly. reminder that
getInternalField
is a bytecode intrinsic (see emit_intrinsic_getInternalField). then we check if it is not defined and take the || path which will call into a native function@createInternalModuleById
(see jsCreateInternalModuleById). the only thing that is slow is the latter call, which is already guarded by a conditional expression.my stance on this pattern is that it is a unnecessary optimization, and that we should actually reverse any places that we do this.
however ... i have not benchmarked the above, and i'm open to being proved wrong.
but then again, i dont think there is any application that the initialization of
util.promisify
on the timer becomes the slow point of an application.