Perf impact on module load seems to be depending on the number of hooks defined.

[pgayvallet]

During our investigations trying to optimize Kibana's startup time, we discovered that the perf impact of using require-in-the-middle was depending on the number of Hook that were defined. (More details in elastic/kibana#178285, but we're talking about ~20% performance gain in total module load time by using only one hook instead of 5)

The implementation of RITM seems to confirm it, given each instance of Hook is patching Module.prototype.require, therefor patching the already-patched require from the previous Hook.

I would expect the library to perform the patching only once, and handle all the registered hooks from this single patched method. It would avoid the interception logic to be executed each time for each hook, for each import.

[trentm]

Thanks for creating the issue!

I would expect the library to perform the patching only once, and handle all the registered hooks from this single patched method. It would avoid the interception logic to be executed each time for each hook, for each import.

Yes, definitely, that would be very nice to have.

It is for this performance reason that OpenTelemetry JS added a separate "RequireInTheMiddleSingleton" class to handle reducing the number of separate Hooks created: https://github.com/open-telemetry/opentelemetry-js/blob/1b4999f386e0240b7f65350e8360ccc2930b0fe6/experimental/packages/opentelemetry-instrumentation/src/platform/node/RequireInTheMiddleSingleton.ts#L45-L53