Le problème avec tous les pipelines, c'est que vous doublez essentiellement le travail. Quelle que soit la rapidité de la décompression, les données doivent toujours être transférées vers un autre processus.
Perl a PerlIO :: gzip qui vous permet de lire directement les flux gzippés. Par conséquent, il pourrait offrir un avantage même si sa vitesse de décompression peut ne pas correspondre à celle de 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]': $!";
Je l'ai essayé avec un fichier compressé gzip de 13 Mo (décompresse à 1,4 Go) sur un ancien MacBook Pro 2010 avec 16 Go de RAM et un vieux ThinkPad T400 avec 8 Go de RAM avec le fichier déjà dans le cache. Sur Mac, le script Perl était significativement plus rapide que l'utilisation de pipelines (5 secondes contre 22 secondes), mais sur ArchLinux, il a perdu à unpigz:
$ time -p ./gzlc.pl spy.gz
1154737
réel 4,49
utilisateur 4.47
sys 0,01
contre
$ time -p unpigz -c spy.gz | wc -l
1154737
réel 3,68
utilisateur 4.10
sys 1.46
et
$ time -p zcat spy.gz | wc -l
1154737
réel 6,41
utilisateur 6.08
sys 0.86
De toute évidence, l'utilisation unpigz -c file.gz | wc -l
est la gagnante ici en termes de vitesse. Et, cette simple ligne de commande bat sûrement l'écriture d'un programme, aussi court soit-il.