Продуктивність циклу та розширення

Потрібні експертні пропозиції щодо порівняння нижче:

Сегмент коду за допомогою циклу:

for file in `cat large_file_list`
do
    gzip -d $file
done

Сегмент коду за допомогою простого розширення:

gzip -d `cat large_file_list`

Який буде швидше? Доводиться маніпулювати великим набором даних.

Ускладнення

Наступне працює лише іноді:

gzip -d `cat large_file_list`

Три проблеми (в bashбільшості інших оболонок Борна):

1. Він не вдасться, якщо будь-яке ім'я файлу має в ньому пробіл або символи нового рядка (припустимо, $IFSщо не було змінено). Це через розшарування слова оболонки .

2. Він також може вийти з ладу, якщо будь-яке ім'я файлу містить в собі глобально активні символи. Це тому, що оболонка застосує розширення імені шляху до списку файлів.

3. Він також вийде з ладу, якщо імена файлів починаються з -(якщо POSIXLY_CORRECT=1це стосується лише першого файлу) або будь-якого імені файлу -.

4. Він також вийде з ладу, якщо в ньому занадто багато імен файлів, щоб вміститися в одному командному рядку.

Код нижче зазнає тих же проблем, що і код вище (за винятком четвертої)

for file in `cat large_file_list`
do
    gzip -d $file
done

Надійне рішення

Якщо у вас large_file_listє саме одне ім’я файлу в рядку, а названий файл -не є серед них, і ви перебуваєте в системі GNU, тоді використовуйте:

xargs -rd'\n' gzip -d -- <large_file_list

-d'\n'повідомляє xargsобробляти кожен рядок введення як окреме ім'я файлу.

-rговорить xargsне запускати команду, якщо вхідний файл порожній.

--говорить, gzipщо такі аргументи не слід розглядати як варіанти, навіть якщо вони починаються з -. -поодинці все ще трактуватимуться як -замість файлу, який називається -.

xargsбуде розміщувати багато імен файлів у кожному командному рядку, але не так багато, щоб воно перевищувало ліміт командного рядка. Це зменшує кількість разів, коли gzipпроцес повинен бути запущений, і тому робить це швидким. Це також безпечно: імена файлів також будуть захищені від розбиття слів та розширення імені шляху .

Я сумніваюся, це мало б значення.

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

Моя петля виглядала б так

while IFS= read -r name; do
    gunzip "$name"
done <file.list

Це додатково дозволить мені вставити команди для обробки даних після gunzipкоманди. Насправді, залежно від того, що насправді є даними, і що з ними потрібно робити, обробляти їх можливо навіть без збереження у файлі:

while IFS= read -r name; do
    zcat "$name" | process_data
done <file.list

(де process_dataдеякий конвеєр, який читає нестиснені дані зі стандартного вводу)

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

В ідеалі я хотів би не хотіти опрацьовувати список імен файлів, а замість цього використовувати шаблон глобулінгу назви файлів, як у

for name in ./*.gz; do
    # processing of "$name" here
done

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

Пов'язані:

• Розуміння "IFS = read -r рядок"

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

Але я хотів би нагадати золоте правило оптимізації : Не робіть цього передчасно.

1. Не оптимізуйте подібні речі, перш ніж ви зрозумієте, що це проблема.

   Чи займає ця частина програми тривалий час? Ну, може, розпакувати великі файли, і вам це доведеться все одно робити, тому відповісти на це може бути не так просто.

2. Виміряйте. Дійсно, це найкращий спосіб бути впевненим.

   Результати ви побачите на власні очі (або власним секундоміром), і вони застосовуватимуться до вашої ситуації, на яку випадкові відповіді в Інтернеті можуть не бути. Покладіть обидва варіанти в сценарії та запустіть time script1.sh, і time script2.sh. (Зробіть це зі списком порожніх стислих файлів, щоб виміряти абсолютну кількість накладних витрат.)

Наскільки швидко ваш диск?

Для цього слід використовувати всі ваші процесори:

parallel -X gzip -d :::: large_file_list

Тож ваш ліміт, швидше за все, буде швидкістю вашого диска.

Ви можете спробувати налаштувати за допомогою -j:

parallel -j50% -X gzip -d :::: large_file_list

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