Array vs TypedArray performance question

[albe]

I see a huge performance difference for the two that I can't explain from the documented behavior of new UInt32Array(ArrayBuffer, offset, length)

https://gist.github.com/albe/39c7b79f46daa49d2cf373ffab3c4513

Can someone explain why this is significantly slower than new array + array assignments?

I'd really like to understand this.

[devsnek]

you're not meant to create views like this, you should create the view once and use it in your loops.

[addaleax]

Maybe to clarify a bit: While JS engines probably could optimize out the typed array creation, at least V8 currently doesn’t. That comes with allocation and object creation overhead.

[albe]

@devsnek that doesn't fit my use case - I thought I could optimize my current array creation + assignment by just creating typed views on already existing buffers instead of copying values. I need one object per 16 bytes of data.

Thanks for the fast reply! So the array instanciation and assignments are indeed that optimized that they do outperform the single object creation involved in the typed array? By nearly one order of magnitude? Striking to say the least, but also shows how highly optimized "standard JS" is in V8.

[addaleax]

@albe I once overhead a JS engine developer say (slightly tongue-in-cheek) that the only thing typed arrays are really better at than plain Arrays is fast passing of data between JS and native code :)

You can also assume that the 8-bit and 16-bit typed arrays comes with lower memory usage than plain Arrays (which is going to matter for large arrays), and plain Arrays don’t quite give you the same behavior when it comes to e.g. value range guarantees for entries, but that’s mostly it, I think.

[albe]

the only thing typed arrays are really better at than plain Arrays is fast passing of data between JS and native code

Hah! If that ever becomes a use-case for me, I'll remember :)

Another interesting observation: Creating a custom class, that just holds a reference to the buffer and offset, then uses readUInt32LE() on demand will perform at ~2,8M ops/sec for the above benchmark. So whatever UInt32Array does, it's much more than just the object creation and referencing of the buffer for access. Maybe some ref counting on the buffer location which involves an additional allocation?

Also found Buffer.copy() to perform worse than 4 individual writeUInt32LE() calls. Guess more safeguards (memory overlap) in copy and method calls are relatively fast?

In general, nodejs seems not too optimized for direct memory data juggling, which is much needed for most lower level protocol implementations. It's totally reasonable seeing from where nodejs comes from though. Hope to see some improvements in the future :)