-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
util: increase robustness with primordials #41212
Conversation
43d5713
to
38706cc
Compare
Seemingly related CI failure:
|
0208d7d
to
fb6af9a
Compare
fb6af9a
to
96f3f53
Compare
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.
The current implementation is much better performance wise and that was the reason for me implementing it like that. As such I would like to keep it as is.
@BridgeAR are there tests that preserve the performance? I'm surprised that a single regex replace would be slower than multiple loops over the string, but i'm also confused why performance is particularly important on a debugging method. |
Here is a short benchmark (the second one is with the regular expression): util.inspect is not only used for debugging. It is in fact used in a lot of production code as it allows to serialize lots of things. It has been a performance bottlenecks in real applications years ago before optimizing the performance. Now it is mostly fine and we should try to keep that. |
Alrighty. I'll update this PR to revert the regex refactor. It seems like if the performance here is important, there should be benchmarks which would fail on a PR that makes it slower - then it wouldn't fall on one person to be paying attention to ensure things aren't slowed down. |
We discussed such performance tests before but they would have to verify too many cases and take too long to be run regularly. We do have benchmarks in place to run though. |
I've updated the PR to revert the regex change, and only leave the primordial changes. In the event the TSC makes a decision that changes the status quo such that these changes are no longer desirable, I will be happy to volunteer to make a PR to remove these, but I hope that until that decision, the status quo means they should land. |
Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1063/
|
@aduh95 I'm not sure how to read it, but if it includes my latest commit then it wouldn't show the impact of the regex implementation, unfortunately. |
@BridgeAR now that this no longer includes the regex, would you be willing to rereview, or dismiss your block? |
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.
Benchmark result looks fine to me.
@BridgeAR ping again? |
I would like to have a conclusion about the primordials before changing things in that direction further. |
@BridgeAR until there is such a decision, why not continue with the status quo? (see #41212 (comment) also) |
Given that this does not significantly expand primordials usage, and that @ljharb is volunteering to undo the primordials later if that's the decision, and that there's no reason to believe that we will imminently arrive at a decision on primordials (although we are making progress, just slow progress), I think we should land this. @BridgeAR What do you think? |
Landed in 098eac7 |
Hi @ljharb! This PR didn't land cleanly on v18.x. Could you please create a backport? |
(backported from nodejs#41212)
Filed #44797 |
(backported from nodejs#41212)
(backported from nodejs#41212)
(backported from nodejs#41212)
PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
(backported from #41212) Backport-PR-URL: #44797 PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs/node#41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs/node#41212 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
I noticed in #41003 that the loop-slice logic in
addNumericSeparator
could be done with a single regex replace.I did not change the implementation of
addNumericSeparatorEnd
because the logic is slightly different, but I can try to do that if desired.cc @nodejs/util