It appears to me from the line:<p><pre><code> 631 if (thisObj->classInfo() == &JSArray::s_info && !asArray(thisObj)->inSparseMode()) {
</code></pre>
that only non-arrays, or arrays in some kind of "sparse" mode are sorted inefficiently.<p>I'm not sure what sparse mode is, but let's try my Raymond Chen inspired psychic powers: if you assign a[0]=1 and a[1000000]=2, you don't want a 1 to 999999 to be stored, so an array like that will end up in a sparse mode which functions more like a hash table keyed by integers.<p>The same applies to non-arrays: since they aren't true arrays, they won't be stored in the blessed, contiguous way that the sort routine is expecting, so a slower access method has to be used.<p>Now, fast sorting is presumably written assuming the array is in a contiguous array. Since in sparse mode the array isn't like that, we aren't on the fast path, so it doesn't matter if we are slow, and correctness and special cases are more important, hence the simple selection sort algorithm.<p>Note also that line 633, 635 and 637 further specialise the fast path into three cases: a default sort with no user-defined comparator, a sort based on a built-in numerical comparator, and a more general sort using a user-defined comparator. (EDIT: The functions called on 633, 635 and 637 are defined in <a href="http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSArray.cpp" rel="nofollow">http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/r...</a> from line 1409 onwards, and use quicksort or mergesort, except in the general case which uses an AVL tree, which feels odd but I'm sure there was a reason.)<p>TL;DR: This only applies to certain arrays; the performance is generally fine else <i>someone would have noticed by now</i>; if you are sorting array-like things or sparse arrays regularly, profile to discover if this is a problem for you.