Splice, slice, pop and shift. Is the array sort method stable and not in-place? It's not easy to remember all JavaScript array methods and what the...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for reading! Let me know if I should post more articles like this by writing a comment or reacting with some of the reactions ❤️🦄 🔥
If you want more memes, you can find those on my Instagram. Enjoy your day!
Nice and complete collection of array methods I will gladly refer to in the future. Potentially also saves you alot of time for these ivory tower code interviews.
Very interesting examples
Excellent article, thank you.
Great article. Thanks!
very helpful article, thank you.
Great post!
Wonderful
Very helpfull article, thank you!
Amazing explanation. thanks for sharing . it will help really helpful.
Very nice post. I have one minor point on the term "in-place" in items 17 and 18 of your post. The specification doesn't actually indicate whether or not either of sort or toSorted uses an in-place sorting algorithm. That decision appears left to the implementation so probably varies by browser or JS runtime. Note that Mozilla claims sort uses an in-place sorting algorithm but that isn't actually in the specification. Returning a new sorted copy of the array, like done by toSorted, instead of modifying original array isn't the same thing as being not in-place. Likewise sorting the original array itself, like done by sort, doesn't require an in-place sorting algorithm. You can do either of these cases with an in-place algorithm or one that is not in-place. It actually looks like the specification indicates that both of these use the same sorting algorithm, without specifying what that algorithm is. The only specific requirement I see is that it must be stable. So these are either both in-place or neither are in-place.
An in-place sorting algorithm is one that uses extra storage that is at most logarithmic in the array length (e.g. insertion sort, heap sort, mergesort with an in-place merge, introsort, etc). If it uses more auxiliary memory than that then it is not in-place, such as mergesort (most fast implementations use linear extra memory during the merge).
In comments on some SO threads, there are arguments over what sorting algorithm is used, or whether some SO answers are out-dated, etc mainly because browsers are free to implement whatever sorting algorithm they wish so the answer varies. It seems that Timsort and Introsort are both currently used in some JS implementations, both of these are in-place sorting algorithms. It is just toSorted sorts and returns a copy rather than sorting the original.
Edit: I can't actually confirm whether Introsort has been used. Saw some claims of that on SO, but is a bit doubtful since it isn't stable and specification requires a stable sort. It looks like Chrome switched from Quicksort to TimSort. Quicksort isn't stable so interesting they had been using it previously.
Thanks for a great comment, you are right. And it's nice to point out the data structures and algorithm perspective of it as well.
I didn't really mention anything about memory consumption since I felt the important thing in this article was about modifying the array or not, which a normal sort for sure does.
I actually checked that Mozilla page when writing the article, but as you mention, they only refer to the ECMA specification with the stability, not for their in-place statement. So that can only speak for Mozilla implementation.
I'm surprised that until they switched to Timsort that Chrome was using a non-stable sort when the specification indicates stable. In-place vs not in-place doesn't matter much unless the array is large enough to stress any memory constraints. Whereas stable vs non-stable may lead to bugs in the application if it relies on stability.