Replies: 2 comments 1 reply
-
Oh sorry, after further debugging it was just that console log from the worker was not redirected to the main thread. My hooks were actually called. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I expect most of the perf difference is the spawning of the loaders thread. /cc @nodejs/loaders |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello, I'm playing around with the
module.register
API and I observe a noticeable performance penalty when it hooks into CJS -> CJS loading.Example setup
hooks.mjs:
main.mjs:
command:
node --import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("./hooks.mjs", pathToFileURL("./"));' ./main.mjs
In this example, no-op customization hooks are set up. Ideally the overhead of the hooks should be minimum, but it adds around 400ms on my machine (Node.js 20.21.0, WSL2), making the whole process 4x slower.
Without hooks:
With hooks:
Most of the added time is spent for communicating with the customization hooks worker synchronously. This can be observed by
NODE_DEBUG=esm
.Excerpts from `NODE_DEBUG=esm` debug logs
Likely using
Atomics
for waiting async operations synchronously has inevitable overheads, which I hope improvements can be made.However, there is another questionable behavior. Instrumenting the hooks code shows that the hooks are run only a few times (resolve
twice andload
twice):This suggests that the registered hooks code is run only when doing ESM -> ESM or ESM -> CJS imports, but not for CJS -> CJS requires. In the CJS -> CJS case, the hooks code is not run, while Node.js still performs communication with the customization hooks worker. I really wonder what work is done, since most of the performance overhead is produced here.EDIT: this wasn't right. My hooks were indeed called but logs weren't printed to the console. I created a separate issue for this: #51668.
I am creating a tool that can read some configuration files written in TypeScript. Currently the module customization hooks are taking 90% of CLI run time, so I am looking for ways to speed up this. My investigation showed the above questionable behavior and I'm really curious why Node.js behaves like this.
Can anyone explain this? Of course, idea for actual performance improvement is super welcome. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions