I did it with just .sort() (labeled as native), but I'm not sure how that compares.
It does affect the sort order though: plain .sort() orders it [numbers, nulls, undefineds], while this orders it like the other implementations, with undefineds being put at the end instead of being filtered, i.e. [nulls, numbers, undefineds].
Feel free to write some more benchmarks yourself, if you want :).
I did those on my Pi 4 4GB, which is slowish.
It gets 24k ops/s for native sort while my phone (Galaxy A51 4GB) gets 30k ops/s.
Update
I remembered something "quirky" about JavaScript's default sorting algorithm: it coerces values to strings and sorts them lexicographically.
The reason the plain sort worked was because all then numbers had the same number of digits. If they had varying numbers, it would have sorted them like this: [2, 20, 3, 30].
I have made updated JSBen.ch benchmarks using arr.sort((a, b) => a - b) (I can't manage to login to JSBench.me):
I did it with just
.sort()
(labeled as native), but I'm not sure how that compares.It does affect the sort order though: plain
.sort()
orders it[numbers, nulls, undefineds]
, while this orders it like the other implementations, withundefined
s being put at the end instead of being filtered, i.e.[nulls, numbers, undefineds]
.Feel free to write some more benchmarks yourself, if you want :).
I did those on my Pi 4 4GB, which is slowish.
It gets 24k ops/s for native sort while my phone (Galaxy A51 4GB) gets 30k ops/s.
Update
I remembered something "quirky" about JavaScript's default sorting algorithm: it coerces values to strings and sorts them lexicographically.
The reason the plain sort worked was because all then numbers had the same number of digits. If they had varying numbers, it would have sorted them like this:
[2, 20, 3, 30]
.I have made updated JSBen.ch benchmarks using
arr.sort((a, b) => a - b)
(I can't manage to login to JSBench.me):