-
Notifications
You must be signed in to change notification settings - Fork 767
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
Inefficient looping in PluginLoader "load" function cause new NodeTracerProvider() to take few seconds in serverless framework #1805
Comments
I'm guilty for this code, however i'm surpised that Anyway that would explain a behavior i have with my one of my applications running at @reelevant-tech where it would take >20s to startup :/ |
@vmarchaud I assume that in most cases the required array is small. |
@blumamir Well we only have one or two packages loaded before otel is loaded in our case and we still saw massive slowdown when enabling otel, i guess that "most cases" is smaller than we can assume with common sense. Thanks for investigating this anyway ! |
@vmarchaud I agree. |
What version of OpenTelemetry are you using?
v0.14.0 (latest)
What version of Node are you using?
12
Please provide the code you used to setup the OpenTelemetry SDK
handler.js
package.json
serverless.yml
What did you do?
run this super basic serverless offline setup with
sls offline
, and sent a request to the exposed endpoint:curl -X POST http://localhost:3000/dev/hello
What did you expect to see?
expect a small increase in the function Duration
What did you see instead?
Additional context
As you can see, calling
new NodeTracerProvider();
is taken ~5 seconds (tested multiple times on my setup).Profiling the issue shows that this section from
PluginLoader
in@opentelemetry/node
is to taking most of the time:This algorithm is very inefficient, running in O(requiredModules)*O(modulesToHook) which can be quite large (in the setup for the above example,
alreadyRequiredModules.length
is 4687 andmodulesToHook.length
is 14 (and expected to grow over time as more plugins are added).The points of inefficiency are:
require.resolve(name)
function from within a loop (alreadyRequiredModules.find
), inside a try-catch, where the value is not expected to change over iterations.alreadyRequiredModules
is an array of strings,find
ing over it takes O(n) (in the above case, 4687 string comparisons per plugin), where we can directly search for the value on the keys ofrequire.cache
in O(1) withhasOwnProperty
.I'll create a PR soon with a suggestion for performence fix, which on my setup, reduces the above section runtime from ~5000ms to just 3ms
The text was updated successfully, but these errors were encountered: