[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Typed Array setter for partial arrays (and typed array performance)
On 22/04/2011 07:25, Kenneth Russell wrote:
> adding another built-in, because in the former case the JIT has a
> chance to generate specialized code, and in the latter case you're
> calling in to and out of the VM's runtime system (typically written in
> C++) which can't perform the same sorts of optimizations.
calling into and out of the VM's runtime system? Also like Ben Vanik, I
would be really surprised if the JIT generated was faster than memcpy().
At best I would expect it to be the same. Lastly my little benchmark
shows that the built-in is much faster (at least on FF4).
I can't agree with your argument.
> I am not personally convinced that we should add this new entry point.
> Especially in low-level APIs like typed arrays, every new one has a
> high maintenance cost. Also, there are API changes lined up which will
> address known performance bottlenecks on the web platform that I think
> should take priority.
> As part of the planned Typed Array API changes to support efficient
> communication with web workers, the plan is to add convenience methods
> to copy ArrayBuffers and possibly sub-portions of them. I think we
> should invest our time in moving those changes forward.
I will certainly track the API changes and make suggestions. I like
Ben's suggestion of real slices but those do not address my use case. I
think support for copying sub-portions of both JS arrays and
ArrayBuffers are really useful. The former because of performance and
the latter because of the garbage generated by making new views or
subarrays solely for the purpose of being the source of a copy.
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660