Improve typedarray's map allocations

[MaxGraey]

Not sure is it necessary optimization. @dcodeIO wdyt?

[dcodeIO]

Hmm, unlike .filter recently, the size of the array is known beforehand in .map, so the overhead here seems to be a single load of .data, right?

[MaxGraey]

Yes, but instantiate<T> internally call memory.fill which could skipped in this case. But yeah this expand size of generated bytecode. That's why I use ASC_SHRINK_LEVEL

[DanielRX]

Does AS explicitly prevent .map being able to edit the original array (3rd param to the function)? Since in JS you have access to the array, is it possible to edit it (reducing the length maybe) which would be a problem?

[MaxGraey]

@DanielRX No, typed arrays hasn't "set" accessor for length so you can't change size of typed arrays after instantiation unlike Array<T>. At least legally (in safe style). And Array#map / TypedArray#map always create new array

[dcodeIO]

Good argument with memory.fill, and I agree that we should avoid instantiate altogether therefore, independently of shrink level. Shouldn't make a significant code size difference anyway since instantiate is basically inlined.

[MaxGraey]

I switched to manual allocs without instantiate. Conditional branch also produce side effect with unnecessary retain/release

[dcodeIO]

LGTM! Do you know if there are other uses of instantiate<T> in stdlib that can be optimized this way?

[MaxGraey]

It seems rest instantiate<T> have necessary usage