iteration order for Object
charles at isomorphic.com
Thu Mar 10 18:18:53 PST 2011
Boris, this is why I also took care to mention that for..in iteration on Arrays should remain
(the use case in the first bug) still have access to a dense-array implementation.
Best of both worlds: Object does what you would expect, Array has optimizations for obscure use
Last point below.
== Objections and counter-arguments
1. Array for..in iteration order has always been inconsistent across browsers
Yes, this is true. I am proposing only that Object preserves insertion order, not Array.
No developers or sites rely on Array for..in iteration order, since it was never consistent.
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.
On 3/10/2011 6:11 PM, Boris Zbarsky wrote:
> On 3/10/11 9:00 PM, Charles Kendrick wrote:
>> People use Objects as classes, instances, "associative arrays" / Maps,
>> etc. Numeric keys are a tiny minority and there would be no measurable
>> performance gains for special treatment of such keys *on Object*.
> You may want to read <https://bugzilla.mozilla.org/show_bug.cgi?id=594655> and
> <https://bugzilla.mozilla.org/show_bug.cgi?id=611423>. People are running into performance
> issues due to lack of such special treatment today.
> Now maybe these people are just doing dumb things they shouldn't be doing, but that doesn't
> make the performance differences observed on those tests "not measurable".
>> However because frameworks have to deal with all possible keys, we end
>> up with a much, much more expensive data structure that has to be used
>> just because numeric keys are being treated specially.
> I agree this is an issue. I just think you're underestimating the performance drag of
> preserving numeric property order for vanilla Objects.
More information about the es-discuss