iteration order for Object
charles at isomorphic.com
Thu Mar 10 18:58:01 PST 2011
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?
>> 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".
More information about the es-discuss