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

これらの3つのコマンドはすべて非常に高速に実行されていますが、不正なカウント28173811が発生しています。

最小限の時間でレコードカウントを実行するにはどうすればよいですか？

sed、perlそしてawkあなたが言及していることのコマンドが正しいかもしれないが、それらはすべて読んで圧縮されたデータを、その中に改行文字をカウントします。これらの改行文字は、非圧縮データの改行文字とは関係ありません。

圧縮されていないデータの行数を数えるには、圧縮を解除する方法はありません。あなたのアプローチzcatは正しいアプローチであり、データが非常に大きいため、それを解凍するのに時間がかかります。

gzip圧縮と解凍を処理するほとんどのユーティリティは、同じ共有ライブラリルーチンを使用してそうする可能性が最も高いでしょう。それを高速化する唯一の方法zlibは、デフォルトのものよりも何らかの形で高速なルーチンの実装を見つけて、例えばzcatそれらを使用するために再構築することです。

unpigzを使用します。

Kusalanandaの答えは正しいです。その内容をスキャンするには、ファイル全体を解凍する必要があります。/bin/gunzipこれを単一コアで可能な限り高速に実行します。Pigzは、gzip複数のコアを使用できる並列実装です。

悲しいことに、通常のgzipファイルの解凍自体は、並列化することはできませんが、pigz改良版の申し出を行いgunzip、unpigzこのよう、読み取り、書き込み、および別のスレッドでチェックサムとして、関連する作業をしています、。いくつかの簡単なベンチマークでunpigzはgunzip、コアi5マシンのほぼ2倍の速度です。

pigzお気に入りのパッケージマネージャーでインストールし、のunpigz代わりにgunzip、またはのunpigz -c代わりに使用しzcatます。したがって、コマンドは次のようになります。

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

これはすべて、ボトルネックがディスクではなくCPUであることを前提としています。

すべてのパイプラインの問題は、本質的に作業が2倍になることです。解凍がどれほど高速であっても、データを別のプロセスにシャトルする必要があります。

Perlには、gzip圧縮されたストリームを直接読み取ることができる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秒対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速度の点で、ここでの使用が勝者です。そして、その単純なコマンドラインは、プログラムの作成を確実に打ち負かしますが、どんなに短くてもです。

Kusalanandaの答えはほとんど正しいです。行を数えるには、改行を検索する必要があります。ただし、ファイルを完全に解凍せずに改行を検索することは理論的には可能です。

gzipはDEFLATE圧縮を使用します。DEFLATEは、LZ77とハフマンエンコーディングの組み合わせです。改行のハフマンシンボルノードだけを把握し、残りを無視する方法があります。L277を使用してエンコードされた改行を探し、バイトカウントを保持し、他のすべてを無視する方法はほぼ確実にあります。

だから私見は、理論的にunpigzやzgrepよりも効率的なソリューションを考え出すことが可能です。言われていることは確かに実用的ではありません（誰かがすでにそれをやっていなければ）。

フラグとパラメーターを使用zgrepして実行でき ます。-c$

この場合、-cは一致した行の数を出力するようにコマンドに指示し、正規表現$は行末に一致するため、すべての行またはファイルに一致します。

zgrep -c $ T.csv.gz 

@StéphaneChazelasがコメントしたように-はただzgrepのスクリプトでzcatありgrep、元の提案と同様のパフォーマンスを提供するはずですzcat | wc -l

ご覧のとおり、ほとんどの答えは、コンテキストスイッチの数とプロセス間IOの数を最適化しようとします。その理由は、ここで簡単に最適化できるのはこれだけだからです。

現在の問題は、そのリソースの必要性が解凍のリソースの必要性にほとんど無視できることです。これが、最適化によって実際には何も速くならない理由です。

本当に高速化できる場合は、修正された非gzip（つまり、解凍）アルゴリズムになり、解凍されたデータストリームの実際の生成は省略されます。むしろ、それだけに改行の数を算出する圧縮解除ストリームから圧縮ひとつ。難しいでしょう。gzipのアルゴリズム（LZWとHuffman圧縮アルゴリズムの組み合わせ）の深い知識が必要です。アルゴリズムは、軽量化によって解凍時間を大幅に最適化することを可能にしない可能性が非常に高く、改行カウントのみを知る必要があります。それが可能であったとしても、本質的に新しいgzip解凍ライブラリが開発されるべきでした（それは知るまで存在しません）。

あなたの質問に対する現実的な答えは、いいえ、あなたはそれを著しく速くすることはできないということです。

もしあれば、並列化されたgzip解凍を使用できます。解凍に複数のCPUコアを使用できます。存在しない場合は、比較的簡単に開発できます。

以下のためにXZ、並列圧縮機（PXZ）が存在します。