Ich versuche, eine Rekordzählung für eine 7,6-GB-gzip-Datei durchzuführen. Ich habe mit dem zcatBefehl nur wenige Ansätze gefunden .

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

Dies funktioniert, aber es dauert zu lange (mehr als 10 Minuten, um die Zählung durchzuführen). Ich habe noch ein paar Ansätze ausprobiert wie

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

Alle drei Befehle werden ziemlich schnell ausgeführt, geben jedoch eine falsche Anzahl von 28173811 an.

Wie kann ich in kürzester Zeit eine Datensatzzählung durchführen?

Die sed, perlund awkBefehle, die Sie erwähnen, mögen korrekt sein, aber alle lesen die komprimierten Daten und zählen darin die Zeilenumbrüche. Diese Zeilenumbruchzeichen haben nichts mit den Zeilenumbruchzeichen in den unkomprimierten Daten zu tun.

Um die Anzahl der Zeilen in den unkomprimierten Daten zu zählen, führt kein Weg daran vorbei, sie zu dekomprimieren. Ihr Ansatz mit zcatist der richtige Ansatz , und da die Daten so groß ist, es wird einige Zeit dauern , um es zu dekomprimieren.

Die meisten Dienstprogramme, die sich mit gzipKomprimierung und Dekomprimierung befassen, verwenden dazu wahrscheinlich dieselben Routinen für gemeinsam genutzte Bibliotheken. Die einzige Möglichkeit, dies zu beschleunigen, besteht darin, eine Implementierung der zlibRoutinen zu finden, die irgendwie schneller als die Standardroutinen sind, und diese beispielsweise neu zcatzu erstellen, um sie zu verwenden.

Verwenden Sie Unpigz.

Kusalananda Antwort ist richtig, Sie werden zu dekomprimieren müssen , dass gesamte Datei seinen Inhalt zu scannen. /bin/gunziperledigt dies so schnell wie möglich auf einem einzigen Kern. Pigz ist eine parallele Implementierung gzip, die mehrere Kerne verwenden kann.

Leider kann die Dekomprimierung normaler gzip-Dateien nicht parallelisiert werden, pigzbietet jedoch eine verbesserte Version von gunzip, unpigzdie verwandte Arbeiten wie Lesen, Schreiben und Prüfsummen in einem separaten Thread ausführt. In einigen schnellen Benchmarks unpigzist es fast doppelt so schnell wie gunzipauf meinem Core-i5-Rechner.

Installieren Sie pigzmit Ihrem bevorzugten Paket-Manager und verwenden Sie unpigzanstelle von gunzipoder unpigz -canstelle von zcat. So wird Ihr Befehl:

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

Das alles setzt voraus, dass der Engpass die CPU ist und nicht die Festplatte.

Das Problem bei allen Pipelines ist, dass Sie die Arbeit im Wesentlichen verdoppeln. Egal wie schnell die Dekomprimierung ist, die Daten müssen immer noch zu einem anderen Prozess verschoben werden.

Perl hat PerlIO :: gzip , mit dem Sie gzippte Streams direkt lesen können. Daher könnte es einen Vorteil bieten, selbst wenn seine Dekomprimierungsgeschwindigkeit nicht mit der folgenden übereinstimmt 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]': $!";

Ich habe es mit einer komprimierten 13-MB-GZIP-Datei (dekomprimiert auf 1,4 GB) auf einem alten 2010 MacBook Pro mit 16 GB RAM und einem alten ThinkPad T400 mit 8 GB RAM versucht, wobei sich die Datei bereits im Cache befindet. Auf dem Mac war das Perl-Skript deutlich schneller als die Verwendung von Pipelines (5 Sekunden gegenüber 22 Sekunden).

$ time -p ./gzlc.pl spy.gz 
1154737
echte 4,49
Benutzer 4.47
sys 0.01

gegen

$ time -p unpigz -c spy.gz | wc -l
1154737
real 3,68
Benutzer 4.10
sys 1.46

und

$ time -p zcat spy.gz | wc -l
1154737
echte 6,41
Benutzer 6.08
sys 0.86

Die Verwendung von unpigz -c file.gz | wc -list hier eindeutig der Gewinner, sowohl in Bezug auf die Geschwindigkeit. Und diese einfache Befehlszeile ist mit Sicherheit besser als ein Programm zu schreiben, wie kurz es auch sein mag.

Kusalanandas Antwort ist größtenteils richtig. Um Zeilen zu zählen, müssen Sie nach neuen Zeilen suchen. Theoretisch ist es jedoch möglich, nach Zeilenumbrüchen zu suchen, ohne die Datei vollständig zu dekomprimieren.

gzip verwendet die DEFLATE-Komprimierung. DEFLATE ist eine Kombination aus LZ77- und Huffman-Codierung. Es kann eine Möglichkeit geben, nur den Huffman-Symbolknoten für Zeilenumbruch herauszufinden und den Rest zu ignorieren. Es gibt mit ziemlicher Sicherheit eine Möglichkeit, nach mit L277 codierten Zeilenumbrüchen zu suchen, die Anzahl der Bytes beizubehalten und alles andere zu ignorieren.

Meiner Meinung nach ist es theoretisch möglich, eine effizientere Lösung als unpigz oder zgrep zu finden. Davon abgesehen ist es sicherlich nicht praktikabel (es sei denn, jemand hat es bereits getan).

Kann mit getan werden zgrep mit -cflag und $parameter durchgeführt werden.

In diesem Fall weist -c den Befehl an, die Anzahl der übereinstimmenden Zeilen auszugeben, und der reguläre Ausdruck $ stimmt mit dem Zeilenende überein, sodass er mit jeder Zeile oder Datei übereinstimmt.

zgrep -c $ T.csv.gz 

Wie kommentiert von @ StéphaneChazelas - zgrepist nur ein Skript um zcatund grepes soll eine ähnliche Leistung auf den ursprünglichen Vorschlag liefernzcat | wc -l

Wie Sie sehen, versuchen die meisten Antworten zu optimieren, was möglich ist: die Anzahl der Kontextwechsel und der prozessübergreifenden E / A. Dies ist der einzige Grund, warum Sie hier einfach optimieren können.

Das Problem ist nun, dass sein Ressourcenbedarf gegenüber dem Ressourcenbedarf der Dekomprimierung nahezu vernachlässigbar ist. Aus diesem Grund werden die Optimierungen nichts wirklich schneller machen.

Wo es wirklich beschleunigt werden könnte, wäre es ein modifizierter Un-Gzip-Algorithmus (dh Dekomprimierungsalgorithmus), der die tatsächliche Erzeugung des dekomprimierten Datenstroms ausschließt. Stattdessen wird nur die Anzahl der Zeilenumbrüche im dekomprimierten Stream aus dem komprimierten berechnet . Es wäre schwierig, es würde tiefe Kenntnisse des gzip-Algorithmus erfordern (eine Kombination der LZW- und Huffman- Komprimierungsalgorithmen). Es ist sehr wahrscheinlich, dass der Algorithmus es nicht möglich macht, die Dekomprimierungszeit mit dem Blitz signifikant zu optimieren. Wir müssen nur die Zeilenumbrüche kennen. Selbst wenn es möglich wäre, hätte im Wesentlichen eine neue gzip-Dekomprimierungsbibliothek entwickelt werden müssen (diese existiert erst, wenn man es weiß).

Die realistische Antwort auf Ihre Frage lautet: Nein, Sie können es nicht wesentlich schneller machen.

Möglicherweise könnten Sie eine parallelisierte gzip-Dekomprimierung verwenden, falls vorhanden. Es könnten mehrere CPU-Kerne für die Dekomprimierung verwendet werden. Wenn es nicht existiert, könnte es relativ leicht entwickelt werden.

Für das xz gibt es einen Parallelkompressor (pxz).