Updates:
Status: WorkingAsIntended
Comment #1 on issue 2190 by [email protected]: 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.
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
