buffer: improve base64 and base64url performance

[anonrig]

The work is mostly done by @lemire.

Suggested changes improves the performance of base64 and base64url operations.

Benchmarks

 confidence improvement accuracy (*) (**) (***)
buffers/buffer-base64-decode-wrapped.js n=32 linesCount=524288 charsPerLine=76 *** 196.05 % ±2.25% ±3.03% ±4.01%
buffers/buffer-base64-decode.js size=8388608 n=32 *** 218.27 % ±3.45% ±4.65% ±6.16%
buffers/buffer-base64-encode.js n=32 len=67108864 *** 2.95 % ±0.67% ±0.89% ±1.16%
buffers/buffer-base64url-decode.js size=8388608 n=32 *** 218.32 % ±4.34% ±5.84% ±7.74%
buffers/buffer-base64url-encode.js n=32 len=67108864 *** 246.27 % ±2.68% ±3.61% ±4.79%
Be aware that when doing many comparisons the risk of a false-positive result increases.
In this case, there are 5 comparisons, you can thus expect the following amount of false-positive results:
0.25 false positives, when considering a 5% risk acceptance (*, **, ***),
0.05 false positives, when considering a 1% risk acceptance (**, ***),
0.01 false positives, when considering a 0.1% risk acceptance (***)

[lemire]

Note that gains are not expected for buffers/buffer-base64-encode.js so the 2.95% result is probably approximately 0%. (I am only pointing out that this is not an issue.)

[Uzlopak]

can we have a btoa too, please?

[anonrig]

@lemire there are some test cases failing. would you mind looking into them?

[lemire]

@Uzlopak@anonrig

can we have a btoa too, please?

This should be "easy".

[lemire]

@anonrig I pushed a commit.

[lemire]

@anonrig I did some additional optimizations.

[mcollina]

lgtm

[lemire]

@anonrig If you get around to it, it would be nice to revisit your benchmarks. I bet that you'd get better numbers with the latest changes.

[anonrig]

@anonrig If you get around to it, it would be nice to revisit your benchmarks. I bet that you'd get better numbers with the latest changes.

The benchmarks didn't show anything, but I'm pretty sure, it has a flaw.

 confidence improvement accuracy (*) (**) (***)
buffers/buffer-base64-decode-wrapped.js n=32 linesCount=524288 charsPerLine=76 *** 191.75 % ±1.82% ±2.45% ±3.25%
buffers/buffer-base64-decode.js size=8388608 n=32 *** 213.25 % ±2.59% ±3.49% ±4.63%
buffers/buffer-base64-encode.js n=32 len=67108864 *** 3.57 % ±1.21% ±1.61% ±2.10%
buffers/buffer-base64url-decode.js size=8388608 n=32 *** 216.97 % ±0.87% ±1.17% ±1.54%
buffers/buffer-base64url-encode.js n=32 len=67108864 *** 244.58 % ±2.97% ±4.00% ±5.31%
Be aware that when doing many comparisons the risk of a false-positive result increases.
In this case, there are 5 comparisons, you can thus expect the following amount of false-positive results:
0.25 false positives, when considering a 5% risk acceptance (*, **, ***),
0.05 false positives, when considering a 1% risk acceptance (**, ***),
0.01 false positives, when considering a 0.1% risk acceptance (***)

[lemire]

The benchmarks didn't show anything, but I'm pretty sure, it has a flaw.

Hmmm...

[github-actions]

The notable-changePRs with changes that should be highlighted in changelogs. label has been added by @anonrig.

Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section.

[lemire]

For people who want profiling... here are the numbers for the base64 decoding prior to this PR:

Here are the results after...

So the main bottleneck after this PR is merged will be memmove. Unless we find a way to move less data, this function is unlikely to ever get much faster.

[nodejs-github-bot]

Landed in 4221631