1.
안정 정렬(Stable sort)이 필요함
프론트엔드에서 정렬은 종종 “여러 키를 순차적으로 정렬”하거나 “뷰 계층에서 이미 정렬된 컬렉션에 세부 정렬을 덧입히는” 경우가 많습니다. 안정 정렬이면 먼저 정렬한 순서를 보존하므로 조합이 쉽고, 사용자 경험 측면에서도 예측 가능합니다.
•
QuickSort는 기본적으로 불안정합니다(특수 구현을 하지 않으면).
•
Timsort는 안정 정렬입니다.
2.
최악의 시간복잡도 보장
QuickSort의 최악은 O(n^2)입니다(피벗이 계속 나쁘게 선택될 때). 대규모/대화형 UI에서 레이턴시 스파이크는 UX를 크게 해칩니다.
•
Timsort는 최악/평균 모두 O(n log n)을 보장합니다.
3.
현실 데이터(부분 정렬·패턴 존재)에 “적응적”
실제 데이터는 완전 무작위가 아니라 이미 어느 정도 정렬(run) 되어 있거나 반전 구간이 짧게 섞인 경우가 많습니다.
•
Timsort는 기존 정렬된 “runs”를 탐지해 재활용합니다. 최선의 경우 O(n)에 가깝게 동작합니다.
•
UI 테이블 정렬, 무한스크롤 누적 정렬, 서버 페이징 후 프론트에서 2차 정렬 같은 시나리오에서 체감 성능이 좋습니다.
4.
메모리 여유와 일관된 성능
브라우저/Node는 보통 **일정 수준의 추가 메모리(O(n))**를 감수하고서도 일관적이고 예측 가능한 성능을 선호합니다.
반면 QuickSort는 메모리 사용은 작지만(평균 O(log n)) 안정성/최악 성능 면에서 불리합니다.
결과적으로,
안정성 + 최악 보장 + 현실 데이터에 강함
Timsort 계열
