title: Chrome re-ordering object keys if numerics, is that normal/expected
body: <p>I noticed that certain code that evaluates some shoe sizes for an e-commerce site and outputs them on screen is messing up the order in Chrome.</p>
  <p>JSON given can be:</p>
  <pre><code>{
    &quot;7&quot;: [&quot;9149&quot;, &quot;9139&quot;, &quot;10455&quot;, &quot;17208&quot;],
    &quot;7.5&quot;: [&quot;9140&quot;, &quot;9150&quot;, &quot;10456&quot;, &quot;17209&quot;],
    &quot;8&quot;: [&quot;2684&quot;, &quot;9141&quot;, &quot;10457&quot;, &quot;17210&quot;],
    &quot;8.5&quot;: [&quot;9142&quot;, &quot;10444&quot;, &quot;10458&quot;, &quot;17211&quot;],
    &quot;9&quot;: [&quot;2685&quot;, &quot;9143&quot;, &quot;10459&quot;, &quot;17212&quot;],
    &quot;9.5&quot;: [&quot;10443&quot;, &quot;9144&quot;, &quot;10460&quot;, &quot;17213&quot;]
  }
  </code></pre>
  <p>...which increments sizes in halves.</p>
  <p>Upon conversion into an object and iterating though the keys, the natural order is being respected and they come out as:</p>
  <blockquote>
  <p>7, 7.5, 8, 8.5 etc.</p>
  </blockquote>
  <p>But in Chrome only, keys that 'look' like round numbers <em>ALWAYS</em> come out of the object first, so output of a for... in loop is:</p>
  <blockquote>
  <p>7, 8, 9, 7.5, 8.5, 9.5 ...</p>
  </blockquote>
  <pre><code>Object.keys(sizes); // [&quot;7&quot;, &quot;8&quot;, &quot;9&quot;, &quot;7.5&quot;, &quot;8.5&quot;, &quot;9.5&quot;]
  </code></pre>
  <p>Here is the test case: <a href="https://jsfiddle.net/wcapc46L/1/" rel="nofollow noreferrer">https://jsfiddle.net/wcapc46L/1/</a></p>
  <p>It's only affects whole numbers, seems like Webkit / Blink have an optimisation that <strong>prefers</strong> Object properties that are numeric, maybe it's to do with Branch Prediction or whatever.</p>
  <p>If you prefix the object keys with any character, the order remains unaffected and works as intended - FIFO</p>
  <p>I think I recall reading that there are no guarantees on the order of properties of an object but at the same time, this is annoying to the extreme and would cause a considerable amount of effort in fixing it for chrome users alone.</p>
  <p>Any ideas? is this likely a bug that will get fixed?</p>
  <p><strong>edit</strong> additionally, I have now discovered this as an issue on the v8 bug tracker:</p>
  <p><a href="https://code.google.com/p/v8/issues/detail?id=164" rel="nofollow noreferrer">https://code.google.com/p/v8/issues/detail?id=164</a></p>
  <p>Looks like Blink don't want to fix this and will remain the only browser that will do it.</p>
  <blockquote>
  <p><strong>update</strong> whatever hash table optimisation webkit/blink had, has now made its way into gecko (FF 27.0.1) - <a href="https://jsfiddle.net/9Htmq/" rel="nofollow noreferrer">https://jsfiddle.net/9Htmq/</a> results in <code>7,8,9,7.5,8.5,9.5</code>. applying <code>_</code> before the keys returns the correct / expected order.</p>
  <p><strong>update 2017</strong> People are still upvoting and editing this so - It does NOT appear to affect <code>Map</code> / <code>WeakMap</code>, <code>Set</code> etc (as demonstrated by updated main example)</p>
  </blockquote>