On Feb 16, 2011, at 5:33 PM, Allen Wirfs-Brock wrote: > On Feb 16, 2011, at 4:54 PM, David Herman wrote: > >> I say: let's make it typed array in the short term, but TC39 will spec it as >> an array of uint32 according to the binary data spec. We will try to make >> the binary data spec as backwards compatible as possible with typed arrays >> anyway. So in the near term, implementors can use typed arrays, but when >> they have implementations of the full binary data spec, they can change to >> use those. It'll probably be a slightly backwards-incompatible change, but >> by keeping them relatively API-compatible, it shouldn't make too much >> difference in practice. Plus we can warn people that that change is coming. > > Dave, most browsers other than FF4 internally box all integers with with > 32-significant bits.
I'm not sure this is still true. Certainly on x64, but also on x86, NaN-boxing has taken over in many VMs. > Some may box with 31 or even 30 significant bits. So if we spec. the value > as a uint32 and (they are truly random enough) then at least half and > possible 75% or more of the values in the array will be boxed in many > browsers. Such boxing will have a much higher cost than immediate uint16 > values. That's why I propose 16-bit values. Given the implementors on es-discuss, we should survey first. I'd hate to prematurely (de-)optimize. I agree with David Wagner that the API has to be dead-simple, and it seems to me having only 16-bit values returned in a JS array may tend to result in more bit-mixing bugs than if we used 32-bit elements, if programmers are carelessly porting code that was written for uint32 arrays. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
