Sto provando a fare un conteggio dei record su un file gzip da 7,6 GB. Ho trovato alcuni approcci usando il zcatcomando.

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

Funziona ma richiede troppo tempo (più di 10 minuti per ottenere il conteggio). Ho provato alcuni altri approcci come

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

Tutti e tre questi comandi si stanno eseguendo abbastanza velocemente ma dando un conteggio errato di 28173811.

Come posso eseguire un conteggio dei record in un tempo minimo?

I sed, perle awkcomandi che si possono citare corrette, ma tutti leggere i compressi dati e conta caratteri newline in quello. Questi caratteri di nuova riga non hanno nulla a che fare con i caratteri di nuova riga nei dati non compressi.

Per contare il numero di righe nei dati non compressi, non è possibile decomprimerlo. Il tuo approccio con zcatè l'approccio corretto e dal momento che i dati è così grande, che si prende il tempo per decomprimerlo.

La maggior parte delle utility che si occupano di gzipcompressione e decompressione molto probabilmente useranno le stesse routine di libreria condivise per farlo. L'unico modo per accelerarlo sarebbe quello di trovare un'implementazione delle zlibroutine che siano in qualche modo più veloci di quelle predefinite, e ricostruire ad esempio zcatper usarle.

Usa unpigz.

La risposta di Kusalananda è corretta, sarà necessario decomprimere che tutto il file per la scansione dei suoi contenuti. /bin/gunziplo fa il più velocemente possibile, su un singolo core. Pigz è un'implementazione parallela gzipche può utilizzare più core.

Purtroppo, la decompressione stessa della normale file gzip non può essere parallelized, ma pigznon offre una versione migliorata di gunzip, unpigz, che fa lavoro relativo, come la lettura, la scrittura, e checksum in un thread separato. In alcuni benchmark rapidi, unpigzè quasi due volte più veloce rispetto gunzipalla mia macchina i5 core.

Installa pigzcon il tuo gestore pacchetti preferito e usa unpigzinvece di gunzip, o unpigz -cinvece di zcat. Quindi il tuo comando diventa:

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

Tutto ciò presuppone che il collo di bottiglia sia la CPU, non il disco, ovviamente.

Il problema con tutte le condutture è che stai sostanzialmente raddoppiando il lavoro. Non importa quanto sia veloce la decompressione, i dati devono comunque essere trasferiti a un altro processo.

Perl ha PerlIO :: gzip che ti permette di leggere direttamente i flussi gzip. Pertanto, potrebbe offrire un vantaggio anche se la sua velocità di decompressione potrebbe non corrispondere a quella di 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]': $!";

L'ho provato con un file compresso gzip da 13 MB (si decomprime a 1,4 GB) su un vecchio MacBook Pro del 2010 con 16 GB di RAM e un vecchio ThinkPad T400 con 8 GB di RAM con il file già nella cache. Su Mac, lo script Perl è stato significativamente più veloce rispetto all'utilizzo di pipeline (5 secondi contro 22 secondi), ma su ArchLinux ha perso unpigz:

$ time -p ./gzlc.pl spy.gz 
1154737
reale 4.49
utente 4.47
sys 0.01

contro

$ time -p unpigz -c spy.gz | wc -l
1154737
3.68 reale
utente 4.10
sys 1.46

e

$ time -p zcat spy.gz | wc -l
1154737
reale 6.41
utente 6.08
sys 0.86

Chiaramente, usando unpigz -c file.gz | wc -lè il vincitore qui sia in termini di velocità. E quella semplice riga di comando batte sicuramente la scrittura di un programma, per quanto breve.

La risposta di Kusalananda è per lo più corretta. Per contare le righe devi cercare nuove righe. Tuttavia è teoricamente possibile cercare nuove righe senza decomprimere completamente il file.

gzip utilizza la compressione DEFLATE. DEFLATE è una combinazione di LZ77 e codifica Huffman. Potrebbe esserci un modo per capire solo il nodo del simbolo di Huffman per newline e ignorare il resto. C'è quasi sicuramente un modo per cercare nuove righe codificate usando L277, mantenere un conteggio di byte e ignorare tutto il resto.

Quindi IMHO è teoricamente possibile trovare una soluzione più efficiente di unpigz o zgrep. Detto questo, non è certamente pratico (a meno che qualcuno non l'abbia già fatto).

Può essere fatto usando zgrepcon -cflag e $parametro.

In questo caso -c indica al comando di produrre il numero di righe corrispondenti e che regex $ corrisponde alla fine della riga in modo che corrisponda a ogni riga o file.

zgrep -c $ T.csv.gz 

Come commentato da @ StéphaneChazelas - zgrep è solo uno script in circolazione zcate grepdovrebbe fornire prestazioni simili al suggerimento originale dizcat | wc -l

Come puoi vedere, la maggior parte delle risposte cerca di ottimizzare ciò che può: il numero di cambi di contesto e I / O tra processi. Il motivo è che questo è l'unico cosa che puoi ottimizzare facilmente qui.

Ora il problema è che la sua necessità di risorse è quasi trascurabile per la necessità di risorse della decompressione. Questo è il motivo per cui le ottimizzazioni non renderanno davvero nulla più veloce.

Dove potrebbe essere realmente accelerato, sarebbe un algoritmo un-gzip (ovvero decompressione) modificato, che elimina la produzione effettiva del flusso di dati decompresso; piuttosto calcola solo il numero di newline nel flusso decompresso da quello compresso . Sarebbe difficile, richiederebbe la profonda conoscenza dell'algoritmo di gzip (una combinazione di LZW e algoritmi di compressione Huffman ). È abbastanza probabile che l'algoritmo non consenta di ottimizzare in modo significativo il tempo di decompressione con il fulmine, che abbiamo solo bisogno di conoscere i conteggi di newline. Anche se fosse possibile, in sostanza dovrebbe essere stata sviluppata una nuova libreria di decompressione gzip (non esiste fino a che non lo sapremo).

La risposta realistica alla tua domanda è che no, non puoi renderla significativamente più veloce.

Forse potresti usare una decompressione gzip parallelizzata, se esiste. Potrebbe utilizzare più core della CPU per la decompressione. Se non esiste, potrebbe essere sviluppato relativamente facilmente.

Per xz , esiste un compressore parallelo (pxz).