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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
