循环性能与扩展性能

需要以下比较的专家建议：

使用循环的代码段：

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以及大多数其他类似Bourne的外壳）：

1. 如果任何文件名中包含空格标签或换行符，它将失败（假设$IFS尚未修改）。这是因为shell的单词spliting。

2. 如果任何文件名中包含全球通用字符，也很容易失败。这是因为Shell会将路径名扩展应用于文件列表。

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行”

在这两个文件中，将所有文件传递给单个调用的文件gzip可能会更快，这完全是因为您只需要启动gzip一次。（也就是说，如果命令完全起作用，请参阅其他说明以获取警告。）

但是，我想提醒一下优化的黄金法则：不要过早地做到这一点。

1. 在知道这是一个问题之前，不要优化这种事情。

   程序的这部分需要很长时间吗？好吧，解压缩大文件可能会，而且无论如何您都必须这样做，所以回答起来可能并不容易。

2. 测量。确实，这是确定的最佳方法。

   您将用自己的眼睛（或秒表）查看结果，它们将适用于您的情况，Internet上的随机答案可能不会。将两个变体都放入脚本中并运行time script1.sh和time script2.sh。（使用空的压缩文件列表来执行此操作以测量开销的绝对值。）

您的磁盘有多快？

这应该使用您所有的CPU：

parallel -X gzip -d :::: large_file_list

因此，您的限制可能取决于磁盘的速度。

您可以尝试使用进行调整-j：

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

这将与上一个命令并行运行一半的作业，并且将减轻磁盘负担，因此根据磁盘的不同，它可能会更快。