Fix Float32Array size

[inkeliz]

Before that patch, it creates a wrong Float32Array, based on the size in bytes (count * stride).

That sounds wrong, since Float32Array expect the size in Float32 (4 bytes). This patch replaces it to count * (stride / 4). The size (in bytes) can be compared using count * stride === data.byteLength which will return true.

---

That change improves the performance, on my machine from ~150_000 to ~350_000.

[inkeliz]

I'm not familiar to C# nor .NET.

---

I found the issue while working to port that demo to Golang, and notice significant performance improvement in Golang's implementation (up to ~3.5x faster). Then, I realize that my Golang version is using _sliceLength * 9 and it also crashes when replaced to _sliceLength * stride (maybe because the buffer is smaller than that).

I'm not sure why the current version is not picking trash from the memory and it's not crashing, which was the behavior that I saw on my Go implementation. There's any information about it? Why the buffer is so large and why it's almost zeroed?

[SteveSandersonMS]

That's very helpful, thanks!

I'm not sure why the current version is not picking trash from the memory and it's not crashing

I think if the heap happens to be big enough for the Float32Array to be contained in it, despite being 4x as big as it should be, then there won't be an error and all the trash at the end will be ignored because nothing is reading or writing that part of the Float32Array. But it would crash if the array happens to be too close to the end of the heap, so it's great that you've supplied this fix!