-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
src: make base64 decoding 10-15% faster #2193
Conversation
@@ -150,62 +150,83 @@ static const int unbase64_table[] = | |||
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, | |||
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 | |||
}; | |||
#define unbase64(x) unbase64_table[(uint8_t)(x)] | |||
#define unbase64(x) \ | |||
static_cast<uint8_t>(unbase64_table[static_cast<uint8_t>(x)]) |
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.
very minor nit. Is four spaces here, okay?
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.
Should we really cast the result to uint8_t
when the actual data is int8_t
?
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.
Yes. The alternative was to change the type of the list elements to uint8_t
but then I'd also have to change all the -1
to 255
to squelch compiler warnings. It would make the diff a lot noisier for no reason; conversion from signed to unsigned is well-defined.
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.
Is four spaces here, okay?
I don't think we really have a convention for that but I'll change it to two spaces before landing.
7f8acb6
to
a5df468
Compare
Incorporated feedback, PTAL. @trevnorris Good suggestion about force-flattening the string first. I'm confident saying now that it's actually 50% faster. :-) |
LGTM |
@bnoordhuis then I guess you can rename this PR :) great job! |
Make the inner loop execute fewer compare-and-branch executions per processed byte, resulting in a 50% or more speedup. This coincidentally fixes an out-of-bounds read: while (unbase64(*src) < 0 && src < srcEnd) Should have read: while (src < srcEnd && unbase64(*src) < 0) But this commit removes the offending code altogether. Fixes: nodejs#2166 PR-URL: nodejs#2193 Reviewed-By: Trevor Norris <trev.norris@gmail.com>
parallel/test-buffer called `Buffer.prototype.toString()` on a buffer with uninitialized memory. Call `Buffer.prototype.fill()` on it first. PR-URL: nodejs#2193 Reviewed-By: Trevor Norris <trev.norris@gmail.com>
a5df468
to
ac70bc8
Compare
Landed in 8fd3ce1 and ac70bc8 with hex values, thanks everyone. I only added @trevnorris in the Reviewed-By because he was the only one to formally LGTM it. |
Is it going to be in 2.5.0, 3.0 or both? |
@YuriSolovyov 2.5.0+ (both) :) |
Make the inner loop execute fewer compare-and-branch executions per
processed byte, resulting in a 10-15% speedup.
This coincidentally fixes an out-of-bounds read:
Should have read:
But this commit removes the offending code altogether.
Fixes: #2166
R=@trevnorris?
CI: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/155/