Чому існує така різниця у часі виконання ехо та кота?

Відповідаючи на це запитання, я змусив поставити ще одне запитання:
я вважав, що наступні сценарії роблять те саме, а другий повинен бути набагато швидшим, тому що перший використовує catте, що потрібно відкривати файл знову і знову, але другий відкриває файл лише один раз, а потім просто повторює змінну:

(Правильний код див. У розділі оновлення.)

Спочатку:

#!/bin/sh
for j in seq 10; do
  cat input
done >> output

Друге:

#!/bin/sh
i=`cat input`
for j in seq 10; do
  echo $i
done >> output

при цьому вхід становить близько 50 мегабайт.

Але коли я спробував другий, він був занадто повільним, оскільки повторення змінної iбуло масовим процесом. У мене також виникли деякі проблеми з другим сценарієм, наприклад, розмір вихідного файлу був меншим, ніж очікувалося.

Я також перевірив довідкову сторінку echoта catпорівняв їх:

echo - відображення рядка тексту

cat - об'єднати файли та друкувати на стандартному виході

Але я не зрозумів різниці.

Так:

• Чому кішка така швидка, а відлуння так повільне у другому сценарії?
• Або проблема зі змінною i? (тому що на сторінці чоловіка на echoньому сказано, що він відображає "рядок тексту", і тому, я думаю, він оптимізований лише для коротких змінних, а не для дуже дуже довгих змінних, наприклад i. Однак це лише здогад.)
• І чому у мене виникли проблеми під час використання echo?

ОНОВЛЕННЯ

Я використовував seq 10замість `seq 10`неправильно. Це відредагований код:

Спочатку:

#!/bin/sh
for j in `seq 10`; do
  cat input
done >> output

Друге:

#!/bin/sh
i=`cat input`
for j in `seq 10`; do
  echo $i
done >> output

(Особлива подяка роайма .)

Однак це не суть проблеми. Навіть якщо цикл виникає лише один раз, я отримую ту ж проблему: catпрацює набагато швидше, ніж echo.

Тут слід розглянути кілька речей.

i=`cat input`

може бути дорогим, і між оболонками може бути багато варіацій.

Це особливість, яка називається підміна команд. Ідея полягає у збереженні всього виводу команди за мінусом знаків нового рядка у iзмінну в пам'яті.

Для цього оболонки розщеплюють команду в підпакеті і читають її вихід через трубу або сокетпар. Ви бачите тут багато варіацій. У файлі 50MiB тут я бачу, наприклад, що bash у 6 разів повільніше ksh93, але трохи швидше, ніж zsh і вдвічі швидше yash.

Основна причина bashповільності полягає в тому, що він читає з труби 128 байтів одночасно (в той час як інші оболонки читають 4KiB або 8KiB одночасно) і карається накладними викликами системи.

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

Усі оболонки повинні знімати символи нового рядка, які вони можуть робити більш-менш ефективно.

Деякі можуть захотіти обробляти байти NUL більш витончено, ніж інші, і перевірити їх наявність.

Потім, коли у вас є така велика змінна пам'ять, будь-яка маніпуляція з нею, як правило, передбачає розподіл більше пам'яті та копіювання даних поперек.

Тут ви передаєте (мали намір передати) вміст змінної в echo.

На щастя, echoвін вбудований у вашу оболонку, інакше виконання, ймовірно, не вдалося б із списком аргументів занадто довгою помилкою. Вже тоді побудова масиву списку аргументів, можливо, передбачає копіювання вмісту змінної.

Інша основна проблема у вашому підході до заміни команди полягає в тому, що ви викликаєте оператор split + glob (забувши процитувати змінну).

Для цього оболонки повинні сприймати рядок як рядок символів (хоча деякі оболонки не мають і є помилковими в цьому відношенні), так що в локалі UTF-8, це означає розбір послідовностей UTF-8 (якщо це не зроблено вже так, як yashце робиться) , шукайте $IFSсимволів у рядку. Якщо $IFSміститься пробіл, вкладка або новий рядок (що за замовчуванням є), алгоритм є ще складнішим і дорогішим. Потім слова, отримані в результаті розщеплення, потрібно виділити та скопіювати.

Глобальна частина буде ще дорожчою. Якщо будь-які з цих слів містять Глоби символи ( *, ?, [), то оболонка буде читати вміст деяких каталогів і зробити деякий дорогою по шаблоном ( bashреалізація «s, наприклад , як відомо , дуже погано в цьому).

Якщо вхід містить щось подібне /*/*/*/../../../*/*/*/../../../*/*/*, це буде надзвичайно дорогим, оскільки це означає перелік тисяч каталогів і може розширитися до декількох сотень МіБ.

Тоді echoзазвичай виконується додаткова обробка. Деякі реалізації розширюють \xпослідовності аргументу, який він отримує, що означає розбір вмісту і, можливо, інше розподілення та копіювання даних.

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

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

Якщо ви хочете додатково оптимізувати це, замість того, щоб викликати catкілька разів, просто перейдіть inputдо цього cat.

yes input | head -n 100 | xargs cat

Запустить 3 команди замість 100.

Щоб зробити змінну версію більш надійною, вам потрібно буде скористатися zsh(інші оболонки не можуть впоратися з байтами NUL) і зробити це:

zmodload zsh/mapfile
var=$mapfile[input]
repeat 10 print -rn -- "$var"

Якщо ви знаєте, що вхід не містить байтів NUL, то ви можете надійно зробити це POSIXly (хоча він може не працювати там, де printfне вбудований) за допомогою:

i=$(cat input && echo .) || exit # add an extra .\n to avoid trimming newlines
i=${i%.} # remove that trailing dot (the \n was removed by cmdsubst)
n=10
while [ "$n" -gt 10 ]; do
  printf %s "$i"
  n=$((n - 1))
done

Але це ніколи не буде більш ефективним, ніж використання catв циклі (якщо тільки вхід не дуже малий).

Проблема не в тому, catа echoв забутій змінній цитати $i.

У скрипті оболонки, подібному до Борна (крім zsh), залишаючи змінними без котировки причину glob+splitоператорів змінних.

$var

насправді:

glob(split($var))

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

Ви можете процитувати змінну для запобігання, glob+splitале вона не допоможе вам сильно, оскільки коли оболонці все-таки потрібно створити аргумент великого рядка і просканувати його вміст на echoпредмет (Заміна вбудованого echoна зовнішній /bin/echoдасть вам список аргументів занадто довгий або не має пам’яті залежать від $iрозміру). Більшість echoреалізацій не сумісні з POSIX, вони розширять \xпослідовність зворотних косої риски в отриманих аргументах.

З cat, оболонці потрібно лише породжувати обробку кожної ітерації циклу і catвиконувати копію введення-виводу. Система також може кешувати вміст файлів, щоб зробити процес кішки швидшим.

Якщо ви телефонуєте

i=`cat input`

це дозволяє вашому процесу оболонки зрости на 50 Мб до 200 МБ (залежно від внутрішньої широкої реалізації символів). Це може зробити вашу оболонку повільною, але це не головна проблема.

Основна проблема полягає в тому, що команда, подана вище, повинна прочитати весь файл в пам'яті оболонки, і echo $iпотрібно зробити розділення поля на вміст цього файлу в $i. Для того, щоб зробити розбиття полів, весь текст з файлу потрібно перетворити на широкі символи, і саме тут витрачається більша частина часу.

Я зробив кілька тестів з повільним випадком і отримав такі результати:

• Найшвидший - ksh93
• Далі - мій Борн Шелл (у 2 рази повільніше, ніж кш93)
• Далі йде баш (у 3 рази повільніше, ніж ksh93)
• Остання - ksh88 (на 7 разів повільніше, ніж ksh93)

Причина, чому ksh93 є найшвидшим, здається, в тому, що ksh93 використовується не mbtowc()від libc, а з власної реалізації.

BTW: Стефан помиляється, що розмір читання має певний вплив, я склав оболонку Борна для читання в 4096 байтових фрагментах замість 128 байт і отримав однакову продуктивність в обох випадках.

В обох випадках цикл буде виконуватися всього двічі (один раз для слова seqі один раз для слова 10).

Крім того, обидва об'єднають сусідній пробіл та відкинуть пробіл / кінець пробілу, так що вихід не обов'язково має дві копії вводу.

Спочатку

#!/bin/sh
for j in $(seq 10); do
    cat input
done >> output

Друге

#!/bin/sh
i="$(cat input)"
for j in $(seq 10); do
    echo "$i"
done >> output

Однією з причин того, чому echoповільніше, може бути те, що ваша котируемая змінна розділяється на пробіли на окремі слова. Для 50MB це буде багато роботи. Цитуйте змінні!

Я пропоную вам виправити ці помилки, а потім переоцінити свої терміни.

Я перевірив це локально. Я створив файл 50MB, використовуючи вихідний файл tar cf - | dd bs=1M count=50. Я також розширив цикли для виконання з коефіцієнтом x100, щоб тимчасові позначки були масштабовані до розумного значення (я додав ще цикл навколо всього вашого коду: for k in $(seq 100); do... done). Ось терміни:

time ./1.sh

real    0m5.948s
user    0m0.012s
sys     0m0.064s

time ./2.sh

real    0m5.639s
user    0m4.060s
sys     0m0.224s

Як бачите, немає реальної різниці, але якщо що-небудь, то версія, яка містить echo, працює трохи швидше. Якщо я видаляю лапки і запускаю вашу розбиту версію 2, час подвоюється, показуючи, що оболонці доведеться зробити набагато більше роботи, якої слід очікувати.

time ./2original.sh

real    0m12.498s
user    0m8.645s
sys     0m2.732s

read набагато швидше, ніж cat

Я думаю, що кожен може перевірити це:

$ cd /sys/devices/system/cpu/cpu0/cpufreq
───────────────────────────────────────────────────────────────────────────────────────────
$ time for ((i=0; i<10000; i++ )); do read p < scaling_cur_freq ; done

real    0m0.232s
user    0m0.139s
sys     0m0.088s
───────────────────────────────────────────────────────────────────────────────────────────
$ time for ((i=0; i<10000; i++ )); do cat scaling_cur_freq > /dev/null ; done

real    0m9.372s
user    0m7.518s
sys     0m2.435s
───────────────────────────────────────────────────────────────────────────────────────────
$ type -a read
read is a shell builtin
───────────────────────────────────────────────────────────────────────────────────────────
$ type -a cat
cat is /bin/cat

catзаймає 9,372 секунди. echoзаймає .232секунди.

readв 40 разів швидше .

Моє перше випробування, коли $pлунало на екрані, readбуло в 48 разів швидше, ніж cat.

Ціль echoпризначена для розміщення 1 рядка на екрані. Що ви робите у другому прикладі, це те, що ви вміщуєте файл у змінну, а потім друкуєте цю змінну. У першому ви негайно викладете вміст на екран.

catоптимізовано для цього використання. echoне. Також розміщення 50Mb у змінній середовища не є хорошою ідеєю.

Справа не в тому, що швидке відлуння, а в тому, що ти робиш:

В одному випадку ви читаєте з введення та запису на вихід безпосередньо. Іншими словами, все, що читається з введення через кішку, йде на вихід через stdout.

input -> output

В іншому випадку ви читаєте з введення змінної в пам'ять, а потім записуєте вміст змінної у вихідний.

input -> variable
variable -> output

Останнє буде набагато повільніше, особливо якщо вхід становить 50 Мб.