Там (у двоичного дерева) постоянный коэффициент сильно выше. И ещё timsort сокращает количество сравнений. В местах, где сравнения дорогие, а перестановки дешёвые, он может оказаться эффективнее на порядок.
В табличке в статье не приводится оценок количества сравнений и перестановок в зависимости от размера, а зря.
Есть ещё характеристики, которые не приведены там и могут существенно повлиять. Например, сортировка Бэтчера принципиально параллелится изначально. Timsort близка к этому. Хоар параллелится хуже, хотя в общем случае таки неплохо. В общем, тут есть куда копать:)
Именно так в Python и Java. Сравнение — это вызов пользовательского кода (даже для встроенных типов несколько виртуальных вызовов), а перестановка — пара машинных инструкций.
Количество сравнений и перестановок зависит не только от размера, но и от распределения. Для совершенно случайного получим одно, но timsort выгоден тем, что очень хорошо ведёт себя на неслучайных данных. И тут уже зависит от фантазии тестировщика, какие неслучайные последовательности он посчитает близкими к реальности.
no subject
no subject
За третью реплику про "баян" забаню. Ничего личного.
no subject
Если мне не изменяет память, на Хабре, где статьи обычно идут косяками, про timsort тоже было несколько статей.
no subject
no subject
no subject
В табличке в статье не приводится оценок количества сравнений и перестановок в зависимости от размера, а зря.
Есть ещё характеристики, которые не приведены там и могут существенно повлиять. Например, сортировка Бэтчера принципиально параллелится изначально. Timsort близка к этому. Хоар параллелится хуже, хотя в общем случае таки неплохо.
В общем, тут есть куда копать:)
no subject
no subject
Количество сравнений и перестановок зависит не только от размера, но и от распределения. Для совершенно случайного получим одно, но timsort выгоден тем, что очень хорошо ведёт себя на неслучайных данных. И тут уже зависит от фантазии тестировщика, какие неслучайные последовательности он посчитает близкими к реальности.