Discuss performance impact in readme

[callumlocke]

Should this be used in production?

Does it have any general performance penalty, or does it only do any extra work (sourcemap-parsing/traversing) when an error stack trace is actually read?

It would be good to answer these questions in the readme.

[tizmagik]

+1

[saadtazi]

Hi,
I would love to know more about performance too.

When are the sourcemaps loaded? is it when corresponding js file is required?

[atas]

I'd like to know if this can be safely used in production as well.

[mattkime]

+1

[jknight12882]

+1

[jaydp17]

@evanw I guess you should address this to increase the adoption of your library.

[sgerace]

I can comment that this library can have a very significant impact on performance in certain situations. I have a site that uses webworkers to fetch and display lots of image data and when browser-source-map-support.js is included it goes from taking 2.3s to load all of the images to 7.6s (the only difference being including the browser-source-map-support.js script). In addition, without the library while the client is loading content everything stays very responsive (because all the work is being done on the webworker thread) but with the library installed, the client is significantly bogged down.

I haven't really dug into the source code of source-map-support to identify what might be causing this behavior, but I would caution against using this in production.

[sevagsim]

Any updates on this?

[MaxInMoon]

Did someone found a piece of answer? Thank you

[MaxInMoon]

I found here this:

"'.map' files are loaded only with opened DevTools""

Is it related to this issue?

[LinusU]

Is it related to this issue?

No, that is how the browser works, but when this package is loaded it will always load the map files ☺️

[anurbol]

Of course using it in production is a significant overhead. Just a brief look at source-map-support/register (and deeper) shows 560 LOC + requiring path and source-map. Anyway great library, thanks to the authors!!

[lostpebble]

When you say significant, what exactly does that mean? Just 506 lines of code and requiring path and source-map in the grand scheme of running a server is not really something to measure significant performance impact surely? We're not talking about server code size here... We're talking about real performance concerns in regular server use.

I would really like to hear some insight from the authors or other on this. Could we use this in production? Having nice source maps when things go wrong in production is nice too - but obviously if it is significantly impacting performance then I'd rather have it off.

[anurbol]

@lostpebble I meant it is significant if it is not necessary in production, so if that's the case, it should definitely be removed.

Then, significant is not a unit of measure like kilogram. Hence it is subjective and depends on the case, requirements etc. When talking about performance the best thing to do is benchmarks. Do it, compare results with and without the lib, and see if it is OK or not for you.

For me personally loading 560 LOC in production (i.e. if it is necessary only on dev) from a single library is significant. For others may be not.

That said, again big thanks to the authors.

[lostpebble]

@anurbol I understand what you're getting at - and sure, it is quite heavy to add to your production code. But what I'd really to know (and I think the original post is about) is the actual performance impact of having this running on your server. Code / dependency tree size doesn't relate directly to performance to me.

Your comment almost made me remove this dependency from production in the future completely - but upon reading it again I don't think its fair to say that there is a significant overhead because of those reasons.

I'll agree that it might be significant perhaps if your use-case was to load up servers for a single process and destroy them soon afterwards - like maybe Cloud Functions / Lambdas. Then all those extra LOC and dependencies could have a real impact, since we'd care more about startup time.

In any case, would love to hear more input from the creators or others in the know about this.