-
Notifications
You must be signed in to change notification settings - Fork 12
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
fix: improve perf #444
fix: improve perf #444
Conversation
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with |
I honestly don't recall why I added I don't think performance of our error instantiation is a bottleneck, but I appreciate your thorough investigation and fix with receipts nonetheless |
🎉 This issue has been resolved in version 6.1.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
If an Error is instantiated in nodejs, then the Error is enriched with the stacktrace anyway. I could not figure out, in which case the stacktrace could be wrong.
We significantly increase the instantiation speed.
The stacktrace generation is in general the slowest part of the error instantiation. So touching other parts of the code will not change the performance of the error instantiation significantly. E.g. we could check if the query contains a
?
before doing the.replace
calls forclient_secret
andaccess_token
which should boost the performance, but it has no effect, because of the slow instantiation of Errors in general.before:
after: