-
Notifications
You must be signed in to change notification settings - Fork 376
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
perf: improve performance of getMetricAsString in next #548
Conversation
Wonderful, thank you! |
return escapeString(str).replace(/"/g, '\\"'); | ||
} | ||
function escapeString(str) { | ||
return str.replace(/\n/g, '\\n').replace(/\\(?!n)/g, '\\\\'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#546 as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't go for that. I just simplified that regexp. Can roll back if you prefer
@SimenB I didn't realize you had a "next" branch. Should I be landing all PRs against that? Is that just to keep the README aligned with the current npm release? I can move the commits I landed from master to next tonight. |
@zbjornson yeah, landed removal of old nodes and such. I think landing changes there and just releasing a new major would be nice |
@SimenB got it, I will fix up the mess I made and do that going forward. |
Co-authored-by: Dan Shappir <dan.s@nextinsurance.com>
Co-authored-by: Dan Shappir <dan.s@nextinsurance.com>
Co-authored-by: Dan Shappir <dan.s@nextinsurance.com>
Thanks again @shappir! @zbjornson I'll just land |
Co-authored-by: Dan Shappir <dan.s@nextinsurance.com>
Co-authored-by: Dan Shappir <dan.s@nextinsurance.com>
Co-authored-by: Dan Shappir <dan.s@nextinsurance.com>
explicit loops are still much more productive than native methods - explicit loops does not have checks for holes in the array and some other checks, so they benefit in performance compared to native array methods |
@budarin happy to take a PR to that effect 🙂 |
I don't think we wanna add a compilation step at this time. Cool plugin, tho! |
Use
Array.prototype.join
instead string concatenation for constructing Prometheus metric string. This results in improved performance and reduced memory consumption, especially when there's a large amount of dimensions (labels and label values). In addition uses array iteration methods instead of explicit loops.note: there are no tests for exemplar so I could not verify that this functionality works as expected.