buffer: even faster atob#52443
Conversation
benjamingr
left a comment
There was a problem hiding this comment.
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.
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!) |
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #52443 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#52443 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#52443 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

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
atobis discouraged but these performance gains are expected to be basically free.