iteration order for Object

Charles Kendrick charles at isomorphic.com
Thu Mar 10 18:58:01 PST 2011


Boris, compare:

1. tens of thousands of web applications that need to define a sorted map plus perhaps billions 
of JSON messages per day

.. to ..

2. a handful of crypto / computational use cases used by a tiny minority of sites

What should be optimized for?

Note that we don't really even have to choose.  If you tell the guys implementing these crypto 
/ bignum libraries that their code is going to run 6x faster in Firefox if they use an Array, 
they'll probably have switched by Tuesday.

It's a perfectly reasonable and acceptable way to close a bug to say that if you want the best 
performance when using lots of numeric indices, use an Array.

On 3/10/2011 6:35 PM, Boris Zbarsky wrote:
> On 3/10/11 9:18 PM, Charles Kendrick wrote:
>> Boris, this is why I also took care to mention that for..in iteration on
>> Arrays should remain unordered
>
> What does this have to do with the post you're replying to?
>
>> so that developers doing relatively obscure things like crypto evoting in JavaScript (the use
>> case in the
>> first bug) still have access to a dense-array implementation.
>
> The point is that the bignum library there is using vanilla objects, not arrays. And they're
> using numeric property names.
>
>> If Array for..in iteration continues to be unordered, any developer that
>> cares about the tiny
>> performance difference can use an Array to store non-numeric
>> property/value pairs.
>
> 1) They're not doing that now, necessarily, and there's no indication that they'll start.
>
> 2) A factor of 6 is not a "tiny performance difference".
>
> -Boris


More information about the es-discuss mailing list