Improving DataView performance in V8

ingve | 52 points

I'm one of the Google Maps developers that worked on the typed-array version of the loading code - hooray for DataView finally being a viable alternative. :)

aappleby | 6 years ago

This is great. Let's hope they plan to also update TypedArray support in general.

NativeArrays are still like 2x faster than Float32Arrays for matrix math. Probably has to be that way ATM as the math has to be promoted to double and back?

Still, v8 seems to be about 2x slower than SpiderMonkey in this area

http://greggman.github.io/webgl-matrix-benchmarks/matrix_ben...

tokyodude | 6 years ago

It seems from the code snippets that DataViews are strongly typed. So what happens when you load data with the wrong type? Does JavaScript have "undefined behavior"?

saagarjha | 6 years ago

Great article. I didn't know DataView was much slower than TypedArrays. I always prefer DataView over TypedArrays when writing protocols and file formats, because TypedArrays follows system endianness so you cannot set endianness manually. (It is true that big-endian CPU is very rare but I cannot stop worrying about endianness.)

kbumsik | 6 years ago

> we also removed support for indices or offsets that are too large (outside of Smi range) inside the TurboFan-optimized code

What exactly is Smi range? I have a feeling it is something obvious that I'm overlooking.

adzm | 6 years ago