-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
buffer: even faster atob #52443
buffer: even faster atob #52443
Conversation
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 honestly don't see the point in these tbh (since while we're improving our performance we're steering users towards methods that are only there for compat) and believe your time would be better spent optimizing paths that are hot or users.
But this is open source, this is still an improvement and actual changes LGTM.
I think that you have now realized that this is part of a series of pull requests which do include the recommended methods which do get optimized... I do understand people who criticize the optimization of legacy methods, and if we only improved the legacy methods, I would take to heart the criticism, but everything is getting faster. If you look at the code, it is really no harder to optimize everything. It is mostly the same code. The dependency does the heavy lifting... I submit to you that there is a good justification for optimizing the legacy functions at the same time as we optimize the recommended functions: testing. The way we proceeded, we get thorough testing because the same underlying functions are tested multiple times in different ways. As an aside, the legacy functions have functionality that the recommended functions do not have. They are validating, among other things. The recommended functions will accept almost any garbage. That's a design choice and I respect it but some users are likely to be using the legacy methods because they offer more safety due to the validation. |
Yes sorry for the confusion after reviewing the ones related to buffer this makes more sense. Optimizing in general is good the only issue was with optimizing only the APIs we don't want users to use - so these changes LGTM (and sorry for not editing my CR here after reviewing the Buffer changes!) |
Landed in 11c90c1 |
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
PR-URL: nodejs#52443 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
PR-URL: nodejs#52443 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Improves atob slightly more by adding a special case (one-byte non-external): this avoids the overhead of copying the string to 16-bit units. The gains are over 25% on a server with an Intel Ice Lake processor, GCC 12. I expect that gains of the same order will be observed generally.
This is a follow-up to #52381 by @anonrig
And yes, I am aware that the use of
atob
is discouraged but these performance gains are expected to be basically free.