Discuss performance impact in readme #122
Comments
|
+1 |
|
Hi, When are the sourcemaps loaded? is it when corresponding js file is |
|
I'd like to know if this can be safely used in production as well. |
|
+1 |
1 similar comment
|
+1 |
|
@evanw I guess you should address this to increase the adoption of your library. |
|
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 I haven't really dug into the source code of |
|
Any updates on this? |
|
Did someone found a piece of answer? Thank you |
|
I found here this:
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 |
|
Of course using it in production is a significant overhead. Just a brief look at |
|
When you say significant, what exactly does that mean? Just 506 lines of code and requiring 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. |
|
@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. |
|
@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. |
|
|
That's great and all, but there are many edge cases you won't be able to benchmark for and could run into serious issues in production down the line. I'm just appealing for some kind of general consensus about regular server use and the performance impact of this library from people in the know. As this issue shows, there are many others who are curious too and I don't think that's unreasonable. |
|
Ran into the same question and, since the answer is lacking, decided to put it to the test: ran 25k HTTP request through a Koa server (so only tested in NodeJS) with and without source-map-support installed, without any exceptions being thrown. Result: no measurable difference between the runs with or without source-map-support enabled: getting a deviation of max 1% between runs and that deviation is not split by runs with or without support enabled. A quick look at the code also reveals that the support will only have a runtime impact (by default) on:
So, looks like there should only be a performance impact when getting the stacktrace (for logging for example) what actual exceptions occur. So, although not an expert in this library, I'd say it's save to use in production, as I don't mind the little extra overhead in case of exceptions if that will aid investigating problems :-) |
|
Looks like for newer NodeJS versions However I've noticed that using |
|
I'd also be curious to hear if anyone compares the performance of Theoretically, this means |
|
@schickling we have seen the same thing with larger builds using node's native |
Same – see nodejs/node#41541 |
|
Thought I'd add to the conversation - I put together a very simple demo repository that does a timing test for various combinations of node runtime, compiler, and native / 3rd party sourcemap support. https://github.com/mjpowersjr/source-map-performance-demo |
|
Thanks for putting that together; I posted a few questions here: mjpowersjr/source-map-performance-demo#1 Some of the comparisons appear to be apples-and-oranges, which is not at all a bad thing, but it helps to understand the differences. |
|
I have updated the benchmark to fix bugs and test that the generated stack traces are correct: Both
Results for 10000 stack traces.
|
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.
The text was updated successfully, but these errors were encountered: