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.
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.joininstead 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.