Производительность цикла по сравнению с расширением

Из этих двух тот, в котором все файлы передаются одному вызову 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

Эта команда запустит половину заданий параллельно, как и предыдущая команда, и будет меньше нагружать диск, поэтому в зависимости от вашего диска это может быть быстрее.

Осложнения

Следующее будет работать только иногда:

gzip -d `cat large_file_list`

Три задачи (в bashи большинство других борновских -подобных оболочек):

1. Произойдет сбой, если какое-либо имя файла содержит символы табуляции или новой строки (при условии, что $IFSне было изменено ). Это происходит из-за разбиения слов оболочки.

2. Также возможен сбой, если в каком-либо имени файла есть активные символы glob -. Это связано с тем, что оболочка будет применять расширение пути к списку файлов.

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= чтение -r строки"