iteration order for Object
Charles Kendrick
charles at isomorphic.com
Mon Mar 14 13:32:54 PDT 2011
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.
More information about the es-discuss
mailing list