feat: optimize atob and btoa performance

[Chanran]

Same to dankogai/js-base64#186, it might have performance issue like js-base64 when use atob or btob polyfill. So I create pr to optimize it.

[zloirock]

It should use unbound versions of methods like this. After that, please, check performance and show results since unbound methods will cause some slowdown.

[Rudxain]

While we're at optimizations, would pre-allocating like output = Array.from({ length: string.length * 3/4 }) improve perf?

[Chanran]

• use origin 3.44.0 core-js-pure/actual/atob

10ms+minor_gc.json

• use optimized code by changing 3.44.0 node_modules/core-js-pure/modules/web.atob.js:

1ms_minor_gc.json

• test demo

core-js-atob-demo 2.zip

1. npm i
2. npm start
3. copy big_base64_data.txt content to textarea
4. change "Decode Count" to 1000
5. open devtools performance panel and record
6. click "Decode" button

[Chanran]

@zloirock @Rudxain The performance problem is that every character "+=" in earch loop will new a string and drop it. That will lead to minor gc much time.

[Rudxain]

every character "+=" in each loop will new a string and drop it

I understand. What I meant is that an engine/runtime might not infer how much memory needs to be allocated for the output array (I'm talking about your patch, not the old code). So by creating an array with the expected number of elements (and replacing push by indexed-assignment), the engine won't have to realloc

[Chanran]

But I tested when changing to Array.from or var arrayFrom = require('./internals/array-from'), performance will even worse than "[]" in chrome.

[zloirock]

Array.from({ length }) is the worst thing you can do for performance - look at how many observable operations there are by specification. Also, it's a very heavy dependency. You could use Array constructor with length argument. Sure, it should be cached too.

[Chanran]

• use Array constructor and use outputIndex to accelerate

var output = Array(Math.ceil(string.length * 3 / 4));
var outputIndex = 0;
while (position < length) {
    chr = charAt(string, position++);
    bs = bc % 4 ? bs * 64 + c2i[chr] : c2i[chr];
    if (bc++ % 4) output[outputIndex++] = fromCharCode(255 & bs >> (-2 * bc & 6));
}
return output.join('');

• use []

[Chanran]

@zloirock Can the pr be merged?

[zloirock]

@Chanran you haven't fixed that was requested.

Also, please, create array with Array constructor with length and don't forget cache it locally too (var $Array = Array;).

[zloirock]

@Chanran ?

[johnzhou721]

FWIW -- I'd be interested in picking this up if the original author is not available. It'd be a good exercise for me to get down to how some JS internals work.

[Chanran]

@zloirock
Sorry about missing the messages. And welcome @johnzhou721 for picking up too. I will also check this these days.

[johnzhou721]

@Chanran just curious as to how you are testing performance. I think I've gotten the patch done, but I'm not sure if it is performant.

[Chanran]

@Chanran just curious as to how you are testing performance. I think I've gotten the patch done, but I'm not sure if it is performant.

@johnzhou721 There is demo to test. dankogai/js-base64#186 you can try.

[johnzhou721]

@Chanran thanks, I've posted instructions on how to modify the demo to work with core-js over at #1503.

I think this can be closed now, as #1503 is passing tests and working fine locally producing the same strings.