lib,src: iterate module requests of a module wrap in JS #52058
Conversation
|
Review requested:
|
nodejs-github-bot
added
c++
legendecas
force-pushed
the
module/link
branch
2 times, most recently
from
26b9280 to
b201582
Compare
legendecas
force-pushed
the
module/link
branch
2 times, most recently
from
c372b99 to
6daec91
Compare
legendecas
force-pushed
the
module/link
branch
2 times, most recently
from
a79c903 to
572d6b0
Compare
github-actions
bot
removed
the
request-ci
|
Rebased on top of the tip of the main branch. |
github-actions
bot
removed
the
request-ci
github-actions
bot
removed
the
request-ci
| assert.fail('link callback should not be called'); | ||
| }); | ||
| [kLink]() { | ||
| /** nothing to do for synthetic modules */ |
There was a problem hiding this comment.
Doesn't need to be solved in this PR but it seems weird that we provide the link method for SyntheticModule at all....
Avoid repetitively calling into JS callback from C++ in `ModuleWrap::Link`. This removes the convoluted callback style of the internal `ModuleWrap` link step.
github-actions
bot
removed
the
request-ci
|
@joyeecheung thanks, rebased and CI is green. |
| ObjectSetPrototypeOf(dependencyJobs, null); | ||
|
|
||
| // Specifiers should be aligned with the moduleRequests array in order. | ||
| const specifiers = Array(moduleRequests.length); |
There was a problem hiding this comment.
This leads to holey arrays, it might still be better to just use ArrayPrototyprPush since this is in a hot path (I think ArrayPrototypePush can be optimized properly the last time I checked).
There was a problem hiding this comment.
Do you have a figure for it? As far as I can tell with the latest V8 version, using a microbenchmark to allocate a 20-length array with the two patterns, the result is outstanding that pre-allocating could be ~40% faster: https://jsbench.me/9tlvebajbe/1.
There was a problem hiding this comment.
The problem with holey arrays come more from the access instead of the creation, since V8 needs to defend against things like this:
Array.prototype[1] = 1;
let a = Array(2);
a[1]; // 1
There was a problem hiding this comment.
(Also, it's not blocking, I am fine landing with holey arrays, since it's probably still not that much work compared to all the other things the resolution is doing..)
There was a problem hiding this comment.
Thanks for bringing this up. I think in this particular case the array is not accessed repetitively so I'd find pre-allocation would be a good solution here.
legendecas
added
the
commit-queue
nodejs-github-bot
removed
the
commit-queue
|
Landed in d5c7ffd |
Avoid repetitively calling into JS callback from C++ in `ModuleWrap::Link`. This removes the convoluted callback style of the internal `ModuleWrap` link step. PR-URL: #52058 Reviewed-By: Joyee Cheung <[email protected]>
Avoid repetitively calling into JS callback from C++ in `ModuleWrap::Link`. This removes the convoluted callback style of the internal `ModuleWrap` link step. PR-URL: nodejs#52058 Reviewed-By: Joyee Cheung <[email protected]>
Avoid repetitively calling into JS callback from C++ in `ModuleWrap::Link`. This removes the convoluted callback style of the internal `ModuleWrap` link step. PR-URL: nodejs#52058 Reviewed-By: Joyee Cheung <[email protected]>
marco-ippolito
added
the
backport-blocked-v20.x
Avoid repetitively calling into JS callback from C++ in
ModuleWrap::Link. This removes the convoluted callback style of theinternal
ModuleWraplink step.Refs: #51977 (comment)