Stable sort for Array#sort.

[jdalton]

Now that V8 has patched their Array#sort to be stable (see here) it appears that Chakra may be one of the last (or the last) of the browser JS engines (JS Core, SpiderMonkey, V8, etc.) to perform a non-stable sort (see demo).

https://github.com/Microsoft/ChakraCore/blob/0f40413d2e29863edf5f82de14fac41843deb79f/lib/Runtime/Library/JavascriptArray.cpp#L6640-L6675

While not a spec violation, if all engines perform a stable sort we can work towards standardizing it in the TC39.

[pleath]

Have the stable-sorting engines converged on a single behavior, or are they differently stable?

[jdalton]

I don't believe folks have normalized on the type of stable sort. For example JavaScriptCore and SpiderMonkey uses a MergeSort algorithm while V8 now uses Timsort (hybrid of MergeSort and InsertionSort). \cc @mathiasbynens @zenparsing

[mathiasbynens]

Stability is the important bit here, as it’s observable by JS developers. The exact sorting algorithm used behind the scenes is an implementation detail.

[fatcerberus]

Yep, that's the point of a stable sort: Because the relative order of same-comparing items isn't altered, then given identical comparer functions, the same input always produces the same output regardless of the underlying algorithm.

[fatcerberus]

In other words, a stable sort means that:

arr.sort(() => 0);

never moves a single item, by definition. There is no such thing as “differently stable” because all comparison results between two items are well-defined w.r.t. where the item ends up (assuming the return values are self-consistent, at least).

[mathiasbynens]

@fatcerberus I think @pleath might have been referring to the remaining differences in observability. The order in which getters/setters are called is observably different depending on the sorting algorithm used behind the scenes. E.g.

const array = [1, 2, 3];
Object.defineProperty(array, '0', {
  get() { console.log('get'); },
  set(value) { console.log('set'); },
});
array.sort();

$ chakra example.js
get
set

$ spidermonkey example.js
get
set

$ javascriptcore example.js # after replacing console.log() with print()
get
get
set
get
get
set

$ v8 example.js
get
get
set
get
get
set
get
get
set

As stated before, I think these differences are less important than the differences w.r.t. stability.

[fatcerberus]

Okay, that makes sense, thanks. 😃

I would be surprised if there was much real-world code that depended on the exact order of comparisons (particularly because the specification doesn’t mandate an algorithm—and even with the same algorithm the order will change with the number of items in the list), so I’m inclined to agree that stability is the important thing here.

[Penguinwizzard]

The original message implies that there'd be a change to the sort spec after this change is made - is there any indication that this would be the limit of the change to the spec? It'd be unfortunate if we went through the work of replacing the sort implementation, only to then have to re-implement it again if the sort specification gets narrower. Currently, the sort spec allows a great deal of latitude in many regards, and doesn't reflect web reality very well - by spec, many situations would allow us to not sort at all, while the web reality is that we need to make some effort to sort the array reasonably in these situations. I don't think it'd be too surprising if more of these facets were touched upon if the issue of changing the spec to require stability came up...

[schuay]

cc @littledan

To my knowledge, only requiring a stable sorting algorithm has been discussed.

Did you have a specific unspecced situation in mind? In my experience, leaving corner cases - such as the existence of elements on the prototype chain of a sparse array - as unspecified behavior has not been problematic.

[mathiasbynens]

Discussing Array.prototype.sort stability is on the agenda for this month's TC39 meeting: https://github.com/tc39/agendas/blob/master/2018/09.md We'll update this issue based on the committee's feedback.

[littledan]

V8's change came after years of the lack of stability being a very frequent developer complaint about V8, both on Twitter and the bug tracker; I believe it'd be similarly developer-friendly to make this change in ChakraCore, and I support the proposed specification change. I believe previous specification discussions didn't get very far, with the argument that forcing a stable sort could be worse for performance and therefore worse for developers (I'm not sure who exactly made this argument); that argument would be less valid with the demonstration of improving performance in V8's transition.

@schuay and I discussed the possibility of locking down even more things than stability, e.g., not reading up prototype chains for hole-y arrays. My guess is that it would be difficult to sell the committee on this sort of change, and it would risk web compatibility, given our long history of supporting reads through holes across many Array methods.

[rhuanjl]

Adding a note to this topic - I've been experimenting with JS implementations of merge sort and timSort and running on macOS they so far seem significantly faster than CC's quick sort (now that the quickSort actually works properly i.e. since #5670 )

Could a JsBuiltin mergesort or timSort be a good answer to this question?

And... Let me know if you'd like a Pull Request to implement such.

(Unsure if there's a license issue with using timSort - noted that v8's implementation says copyright Python foundation at the top of the file even though it's their own implementation of it - is the algorithm itself copyrighted?)