On Tue, Mar 15, 2016 at 12:00 AM, Vic99999 <[email protected]> wrote:
> @Tab Atkins Jr., > > The only question is how much slower/more expensiver stable sorting is > than unstable sorting, and whether that cost is sufficient to outweigh the > usefulness of a stable sort. > My own experiment shows, that QuickSort (unstable) is ~20% (or more) > faster on "random" array of integers (a good case for QuickSort). Probably, > there are many Chrome users who sort large integer arrays, and so Chrome > devs will never switch to a stable sort. (see comments at > https://bugs.chromium.org/p/v8/issues/detail?id=90 ) > I bet the chrome team would switch it were spec'd that way -- this would put them on an even playing field with other implementations. But yes, 20+% definitely makes the case that if stable sort were spec'd, a hook to get to at any faster unstable sort should be specified as well. But again, unstable sort should be opt-in, used by those that fully grok the implications. Devs who don't really know the difference (a *large* proportion, IME) are very likely to expect stable sort semantics. Correctness should trump performance for the default case.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
