iteration order for Object

[Charles Kendrick]

On 3/12/2011 2:08 AM, Claus Reinke wrote:
> I notice that you don't count initialization for the native Object
> variant. Apart from fixing that,

This is not a flaw.  The initialization phase for the orderedMap creates an index.  This is not 
needed for Object because the Object *is* the index.

> would the following variant help (run, but not tested;-)? It
> keeps the previous/next key in the key's internal value, to reduce overhead.

The primary differences is that your code creates one Array per property, while my code uses 3 
Objects to store unlimited properties via lots of slots.

This makes your code about 4x slower on IE6, where Object/Array allocation has painfully high 
penalties.

On other browsers, the results are less clear: straight timings are not directly comparable 
since at the end of the test, my code has no garbage, whereas yours has orphaned 15,000 arrays 
that the garbage collector needs to clean up.

To sum up, by using different implementations in different browsers, it may be possible to 
implement an order-preserving map in JavaScript and be within 5-6x of native speed.

Which in turn means, a common use case is penalized badly if Object loses order for numeric 
properties, whereas only relatively uncommon use cases (eg crypto in JavaScript) are penalized 
by preserving order for numeric properties.

However, *critically*, these uncommon use cases can regain full speed by using Arrays for 
objects with lots of numeric properties, but there is no known way to get back to full speed 
for the common use case of needing an ordered map.

Finally, this is just one part of the overall argument.  This effect combines with the 
backcompat issue, loss of information going from Object literals to live Objects, less compact 
code and higher allocation/GC costs, etc.