Roch Devost

@Averethel Is the additional memory usage resolved if you disable the `fetch` plugin with `tracer.use('fetch', false)`?

@Averethel It's possible since 4.9.0 to disable the fetch instrumentation (so not just the plugin). Can you try that so we can at least isolate the issue to the integration?...

@webark Is this something you can reproduce with a snippet you could share? I can't reproduce on my end even with the integration enabled, and the [instrumentation](https://github.com/DataDog/dd-trace-js/blob/820101709abe2b153f165a723daed30389aeb56b/packages/datadog-instrumentations/src/fetch.js) also doesn't do...

> I wonder if maybe this is causing some confusion in the garbage collector? Possible, although I doubt it would be to the extent of causing a memory leak since...

> @rochdev is this something you'd still like to land? Not sure, I was really just experimenting. The main benefit would be for serverless. @astuyve Is bundling dd-trace something you'd...

The main issue is that for Express, there is a fixed set of routes that are matched and grouping is done using those. The same thing doesn't exist for HTTP...

In order to automatically rewrite every error stack trace with the correct mapping at runtime, you can use [source-map-support](https://github.com/evanw/node-source-map-support). This has the advantage of working not only with dd-trace, but...

Turns out Node actually supports this out of the box with the [--enable-source-maps](https://nodejs.medium.com/source-maps-in-node-js-482872b56116) flag.

@paambaati It depends if you mean for tracing or for profiling. For tracing, source maps only make sense in the context of errors. We send whatever stack trace is on...

@paambaati Did you also try [source-map-support](https://github.com/evanw/node-source-map-support)? According to the issue it should be a lot faster and should also work with our tracer.