Non-extensibility of Typed Arrays

Brendan Eich brendan at mozilla.com
Wed Sep 4 11:33:02 PDT 2013


Filip Pizlo wrote:
> So, how big are your non-expanddable typed arrays, and what do they 
> look like?  If they're not smaller than 16 bytes in the common case 
> with 32-bit pointers, or 32 bytes in the common case with 64-bit 
> pointers, then there is no performance argument in favor of getting 
> rid of expandable properties.

I like your analysis, it helps greatly to be quantitative and to talk 
concretely about implementation trade-offs. However, I don't think it 
proves as much as you assert.

Suppose I want (as IBM did for years, and may still) to implement IEEE 
754r decimal in JS, with minimal overhead. I would need 128 bits of flat 
storage, no variable length, no .buffer or aliasing, and *no expandos*. 
Can binary data help me do that? If so, how small can the thing be? I'd 
like a multiple of 16 bytes, but on 64-bit targets that does not leave 
enough room for TBLR and we don't really need BLR anyway.

If we can't implement efficient-enough 754r decimal using binary data, 
that's sad. Not the end of the world, and it doesn't prove a whole lot 
about anything (perhaps we'll figure out something next year). But the 
small, fixed-size array case exists (think of Float32Array 4-vectors, 
homogeneous coordinates). It seems to me you are giving this use-case 
short shrift.

/be


More information about the es-discuss mailing list