Чому coreutils сортує повільніше, ніж Python?

Я написав наступний сценарій, щоб перевірити швидкість функціонування Python:

from sys import stdin, stdout
lines = list(stdin)
lines.sort()
stdout.writelines(lines)

Потім я порівняв це з командою coreutils sortу файлі, що містить 10 мільйонів рядків:

$ time python sort.py <numbers.txt >s1.txt
real    0m16.707s
user    0m16.288s
sys     0m0.420s

$ time sort <numbers.txt >s2.txt 
real    0m45.141s
user    2m28.304s
sys     0m0.380s

Вбудована команда використовувала всі чотири процесори (Python використовувала лише один), але запустила приблизно три рази! Що дає?

Я використовую Ubuntu 12.04.5 (32-розрядні), Python 2.7.3 та sort8.13

Коментар Ізката виявив відповідь: порівняння, що стосується конкретних місцевостей. sortКоманда використовує локаль , зазначену навколишнє середовище, в той час як по замовчуванням Python для порівняння порядку проходження байтів. Порівнювати рядки UTF-8 важче, ніж порівнювати байтові рядки.

$ time (LC_ALL=C sort <numbers.txt >s2.txt)
real    0m5.485s
user    0m14.028s
sys     0m0.404s

Як про те, що.

Це скоріше додатковий аналіз, ніж фактичний відповідь, але він, здається, змінюється залежно від сортованих даних. По-перше, базове читання:

$ printf "%s\n" {1..1000000} > numbers.txt

$ time python sort.py <numbers.txt >s1.txt
real    0m0.521s
user    0m0.216s
sys     0m0.100s

$ time sort <numbers.txt >s2.txt
real    0m3.708s
user    0m4.908s
sys     0m0.156s

Добре, пітон набагато швидший. Однак ви можете зробити coreutils sortшвидше, запропонувавши їм сортувати чисельно:

$ time sort <numbers.txt >s2.txt 
real    0m3.743s
user    0m4.964s
sys     0m0.148s

$ time sort -n <numbers.txt >s2.txt 
real    0m0.733s
user    0m0.836s
sys     0m0.100s

Це набагато швидше, але пітон все-таки виграє з великим відривом. Тепер спробуємо ще раз, але з несортиваним списком 1М чисел:

$ sort -R numbers.txt > randomized.txt

$ time sort -n <randomized.txt >s2.txt 
real    0m1.493s
user    0m1.920s
sys     0m0.116s

$ time python sort.py <randomized.txt >s1.txt
real    0m2.652s
user    0m1.988s
sys     0m0.064s

Coreutils sort -nшвидше для несортованих числових даних (хоча ви, можливо, зможете налаштувати параметр сортування python, cmpщоб зробити його швидшим). Coreutils sortвсе ще значно повільніше без -nпрапора. Отже, що з випадковими символами, а не чистими числами?

$ tr -dc 'A-Za-z0-9' </dev/urandom | head -c1000000 | 
    sed 's/./&\n/g' > random.txt

$ time sort  <random.txt >s2.txt 
real    0m2.487s
user    0m3.480s
sys     0m0.128s

$ time python sort.py  <random.txt >s2.txt 
real    0m1.314s
user    0m0.744s
sys     0m0.068s

Python як і раніше перемагає coreutils, але набагато менший запас, ніж той, який ви показуєте у своєму питанні. Дивно, але це все-таки швидше при перегляді чистих алфавітних даних:

$ tr -dc 'A-Za-z' </dev/urandom | head -c1000000 |
    sed 's/./&\n/g' > letters.txt

$ time sort   <letters.txt >s2.txt 
real    0m2.561s
user    0m3.684s
sys     0m0.100s

$ time python sort.py <letters.txt >s1.txt
real    0m1.297s
user    0m0.744s
sys     0m0.064s

Важливо також зазначити, що вони не дають однакового сортованого результату:

$ echo -e "A\nB\na\nb\n-" | sort -n
-
a
A
b
B

$ echo -e "A\nB\na\nb\n-" | python sort.py 
-
A
B
a
b

Як не дивно, але --buffer-sizeваріант, схоже, не міг значно (або будь-яку) різницю в моїх тестах. На закінчення, мабуть, через різні алгоритми, згадані у відповіді Голділок, sortв більшості випадків пітон здається більш швидким, але числовий GNU sortперевершує його на несортні числа ¹ .

ОП, ймовірно, знайшов першопричину, але задля повноти, ось остаточне порівняння:

$ time LC_ALL=C sort   <letters.txt >s2.txt 
real    0m0.280s
user    0m0.512s
sys     0m0.084s


$ time LC_ALL=C python sort.py   <letters.txt >s2.txt 
real    0m0.493s
user    0m0.448s
sys     0m0.044s

¹ _{Хтось, хто має більше пітон-фу, ніж я, повинен спробувати перевірити налаштування, list.sort()щоб побачити однакову швидкість, можна досягти, вказавши метод сортування.}

Обидві реалізації знаходяться на C, тому там рівні умови. Coreutils, sort очевидно, використовує алгоритм злиття . Mergesort робить фіксовану кількість порівнянь, що збільшується логарифмічно до вхідного розміру, тобто великого O (n log n).

Сорт Python використовує унікальний гібридний тип злиття / вставки, timsort , який зробить змінну кількість порівнянь з найкращим сценарієм випадку O (n) - імовірно, у вже відсортованому списку - але, як правило, логарифмічний (логічно, ви не може бути кращим, ніж логарифмічний для загального випадку при сортуванні).

З огляду на два різних логарифмічних сорти, один може мати перевагу над іншим у певному наборі даних. Традиційний сорт злиття не змінюється, тому він буде виконувати те ж саме незалежно від даних, але, наприклад, квакісорт (також логарифмічний), який різниться, буде працювати на деяких даних краще, але на інших гірше.

Коефіцієнт три (або більше 3, оскільки sort є паралельним), хоч і небагато, що змушує мене замислитись, чи немає тут якихось надзвичайних ситуацій, наприклад, sortзаміни на диск ( -Tваріант, мабуть, передбачає, що це робить). Тим не менш, ваш низький сис проти часу користувача означає, що це не проблема.