Issue 2190 in v8: Performance on TypedArray creation low

[codesite...@google.com]

Status: New
Owner: ----

New issue 2190 by timm.dre...@gmail.com: Performance on TypedArray creation
low
http://code.google.com/p/v8/issues/detail?id=2190

Reading and writing to and from existing TypedArrays very fast:
- http://jsperf.com/typedarray-read/2
- http://jsperf.com/typedarray-write/3

But in contrast creating a new TypedArray is very slow:
- http://jsperf.com/typedarray-create

This is a killer for scenarios when you are using temporary objects inside
the functions (Native) in contrast of using an external singleton as
temporary object (TempObj):
- http://jsperf.com/typedarray-lookat/3

if you are using temporary Arrays inside the function (Mixture / Mixture
TempObj) it doesn't result in a huge performance decrease.

[codesite...@google.com]

Updates:
Status: WorkingAsIntended

Comment #1 on issue 2190 by yan...@chromium.org: Performance on TypedArray
creation low
http://code.google.com/p/v8/issues/detail?id=2190

This issue is neither new nor limited to Chrome (as can be seen on jsperf).
The reason is simply that while constructing Array is done exclusively in
the Javascript virtual machine and an allocation in the VM's heap,
constructing a TypedArray involves the browser binding (at least in Chrome)
and allocation outside the VM's heap. The former can be properly optimized,
while the latter cannot. Future optimizations in this area are already on
our radar, but have rather low priority.

The performance difference you see in your read benchmark can simply be
explained by the Array object being uninitialized. Out-of-bound accesses
are inherently slow. I revised your read access benchmark -
http://jsperf.com/typedarray-read/3
The same applies to the write access benchmark: sequential out-of-bound
writes require the array length to be changed every time. Random write
accesses causes the VM to represent the array as a hashtable rather than a
real array in the memory. Those issues do not affect typed arrays since
those are simply allocated as a memory block in the heap.

Generally speaking, typed arrays are good if you want to allocate a
long-living dense array with a certain type and size. Array objects are
better if you want to create temporary arrays often.

However, I would advise against micro-benchmarks like those on jsperf as
those rarely show real-world performance. Javascript VMs nowadays are tuned
with intricate heuristics that often work well for comprehensive
applications, but not for micro-benchmarks that stress one small test case.

[codesite...@google.com]

Comment #2 on issue 2190 by pie...@gmail.com: Performance on TypedArray
creation low
http://code.google.com/p/v8/issues/detail?id=2190

This really is a shame. it would seem that typed, fixed-length arrays
should be much faster than regular JS arrays. TypedArrays (large and small)
are used throughout WebGL.