我正在尝试对7.6 GB gzip文件进行记录计数。我发现使用该zcat命令的方法很少。

$ zcat T.csv.gz | wc -l
423668947

这可以工作，但是需要太多时间（超过10分钟才能获得计数）。我尝试了更多类似的方法

$ sed -n '$=' T.csv.gz
28173811
$ perl -lne 'END { print $. }' < T.csv.gz
28173811
$ awk 'END {print NR}' T.csv.gz
28173811

这三个命令的执行速度都非常快，但计数错误28173811。

如何在最短时间内执行记录计数？

的sed，perl和awk你提到的命令可能是正确的，但他们都读压缩的数据和计数换行符。这些换行符与未压缩数据中的换行符无关。

要计算未压缩数据中的行数，无法解压缩。您采用的方法zcat是正确的方法，并且由于数据非常大，因此解压缩将花费一些时间。

大多数处理gzip压缩和解压缩的实用程序很可能会使用相同的共享库例程来执行此操作。加快速度的唯一方法是找到zlib比默认程序快某种方式的例程的实现，然后重新构建zcat以使用这些例程。

使用unpigz。

Kusalananda的答案是正确的，您将需要解压缩整个文件以扫描其内容。/bin/gunzip在单个内核上以最快的速度完成此操作。Pigz是gzip可以使用多个内核的并行实现。

可悲的是，正常的gzip文件解压缩本身不能并行，但pigz确实提供了一个改进版本gunzip，unpigz即做相关的工作，如阅读，写作，并在一个单独的线程执行校验。在某些快速基准测试中，unpigz速度几乎是gunzip我的核心i5机器的两倍。

安装pigz用你喜欢的包管理器，并使用unpigz替代gunzip或unpigz -c代替zcat。因此，您的命令将变为：

$ unpigz -c T.csv.gz | wc -l

当然，所有这些都假定瓶颈是CPU，而不是磁盘。

所有管道的问题在于，您实际上要加倍工作。无论解压缩有多快，数据仍然需要传递到另一个进程。

Perl具有PerlIO :: gzip，可让您直接读取压缩的流。因此，即使其解压缩速度可能不符合以下条件，它也可能具有优势unpigz：

#!/usr/bin/env perl

use strict;
use warnings;

use autouse Carp => 'croak';
use PerlIO::gzip;

@ARGV or croak "Need filename\n";

open my $in, '<:gzip', $ARGV[0]
    or croak "Failed to open '$ARGV[0]': $!";

1 while <$in>;

print "$.\n";

close $in or croak "Failed to close '$ARGV[0]': $!";

我在具有16 GB RAM的旧2010 MacBook Pro和具有8 GB RAM的旧ThinkPad T400上使用了13 MB gzip压缩文件（解压缩为1.4 GB）进行了尝试，该文件已在缓存中。在Mac上，Perl脚本比使用管道要快得多（5秒vs 22秒），但是在ArchLinux上，它输给了unpigz：

$ time -p ./gzlc.pl spy.gz 
1154737
真正的4.49
用户4.47
sys 0.01

与

$ time -p unpigz -c spy.gz | wc -l
1154737
真实的3.68
用户4.10
sys 1.46

和

$ time -p zcat spy.gz | wc -l
1154737
真正的6.41
用户6.08
sys 0.86

显然，unpigz -c file.gz | wc -l无论是速度还是速度，赢家都是赢家。而且，无论多么简短，该简单的命令行肯定比编写程序要好。

库萨兰南达的答案基本上是正确的。要计算行数，您需要搜索换行符。但是，从理论上讲，无需完全解压缩文件即可搜索换行符。

gzip使用DEFLATE压缩。DEFLATE是LZ77和Huffman编码的组合。也许有一种方法可以只找出霍夫曼符号节点的换行符，而忽略其余部分。几乎可以肯定，有一种方法可以查找使用L277编码的换行符，保留字节数并忽略其他所有内容。

因此，恕我直言，在理论上可能比unpigz或zgrep更有效地提出解决方案。话虽这么说肯定不切实际（除非有人已经这样做了）。

可以使用zgrepwith -c标志和$parameter 来完成 。

在这种情况下，-c指示命令输出匹配的行数，而regex $匹配行尾，因此它匹配每一行或文件。

zgrep -c $ T.csv.gz 

正如@StéphaneChazelas评论说- zgrep只是一个脚本周围zcat和grep它应该到原来的建议提供相似的性能zcat | wc -l

如您所见，大多数答案都试图优化其功能：上下文切换的数量和进程间IO。原因是，这是您可以在此处轻松优化的唯一方法。

现在的问题是，其资源需求与减压的资源需求几乎可以忽略不计。这就是为什么优化不会真正使任何事情更快的原因。

在可以真正加速的地方，将使用修改后的un-gzip（即解压缩）算法，从而省去了实际的解压缩数据流。而它只计算在新行的数目解压缩的流从所述压缩的一个。很难，这需要gzip的算法（LZW和Huffman压缩算法的某种组合）的深入了解。该算法很可能无法通过闪电来显着优化减压时间，而我们只需要知道换行数即可。即使有可能，本质上应该已经开发了一个新的gzip解压缩库（直到知道它才存在）。

对您问题的现实答案是，不，您不能使其明显更快。

也许您可以使用一些并行化的gzip解压缩（如果存在）。它可以使用多个CPU内核进行解压缩。如果不存在，则可以相对容易地进行开发。

对于xz，存在一个并行压缩器（pxz）。