gunzip : system ou bien module ?

À (at) 8 Jun 2004 04:26:29 -0700,
dcd@noos.fr (aarg) écrivait (wrote):

Un script manipule chaque jour un très grand nombre de fichiers .Z
obtenus avec compress : on va les décompresser un par un, puis les
dé-tarer, puis traiter ligne par ligne .

Pour effectuer la décompression, vaut il mieux (en terme de temps
d'exécution) utiliser la fonction system et faire appel à gunzip puis
à tar ou bien sera t-il plus performant de charger et d'utiliser les
modules Archive::Tar et IO::Zlib ?

Le passage par la fonction 'system' et l'appel aux programmes externes
nécessitent des forks qui sont couteux en temps. Il vaut donc mieux utiliser
les modules.

Pendant que j'y suis: pour obtenir la liste des fichiers à traiter je
fais un glob puis un foreach . C'est mieux que opendir, readdir et
while, non ?

À mon avis, la différence de temps est négligeable... sauf si vous traitez de
millions de fichiers. Dans ce cas, il faudrait faire des mesures précises.

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>

On Tue, 08 Jun 2004 04:26:29 -0700, aarg wrote:

Bonjour,

Un script manipule chaque jour un très grand nombre de fichiers .Z
obtenus avec compress : on va les décompresser un par un, puis les
dé-tarer, puis traiter ligne par ligne .

Si c'est seulement pour decompresser un tar.Z j'utiliserais plutôt un GNU
tar avec les options `Zxf' pour tout extraire directement.

Pour effectuer la décompression, vaut il mieux (en terme de temps
d'exécution) utiliser la fonction system et faire appel à gunzip puis
à tar ou bien sera t-il plus performant de charger et d'utiliser les
modules Archive::Tar et IO::Zlib ?

L'inconvenient de `Archive::Tar' (d'après la doc) c'est qu'il charge tout
le tar en mémoire, ce qui peut poser problème pour des gros fichiers tar
De plus le module `Archive::Tar' doit être plus lent que la commande
`tar', mais de l'autre coté du gagne en portabilité (pas besoin d'avoir
la commande `tar' pour Windows par ex.)(mais de toutes façons `IO::Zlib'
est déjà dependant de la zlib)

Si c'est juste pour decompresser une archive, l'usage de `Archive::Tar'
ne se justifie pas AMHA... maintenant si tu dois ajouter, renommer,
supprimer des fichiers de l'archive, alors il pourra être utile...

De plus le module `Archive::Tar' doit être plus lent que la commande
`tar', mais de l'autre coté du gagne en portabilité

Oui, j'ai vu ça également, mais après avoir posté (grr ...).
Qu'en serait il avec le module Compress::Zlib ?
(en gardant un appel système pour le tar mais en remplaçant le gunzip)

Si c'est juste pour décompresser une archive, l'usage de `Archive::Tar'
ne se justifie pas

C'est juste un dézippage + détarrage mais dans une boucle, un tres
grand nombre de fois (quand même pas des millions mais au moins des
milliers ! ).

En remplaçant un appel à system et mv (sic) par foreach et rename, le
script gagne effectivement en performance, et ceci sur un petit nombre
de fichiers.
Mais cela ne fait pas intervenir le chargement d'un module.

Savez vous si le module Compress::Zlib traite indifféremment des
fichiers obtenus avec compress et avec gzip ?

Je vais essayer de tester Compress::Zlib et voir si j'obtiens quelque
chose d'intéressant.

En ce qui concerne le glob : je trouvais ça plus logique que d'ouvrir
un handle etc. mais en effet il n'y a pas de différence sur le jeu de
test. Il y a même des erreurs de glob ! Je pense que ceci est du à la
version de perl sur ce serveur : 5.005_03 (je vais également essayer
de faire quelque chose à ce sujet, car si on me demande d'optimiser
... )

Merci de vos avis,

dav'

À (at) 9 Jun 2004 08:41:43 -0700,
dcd@noos.fr (aarg) écrivait (wrote):

De plus le module `Archive::Tar' doit être plus lent que la commande
`tar', mais de l'autre coté du gagne en portabilité

Oui, j'ai vu ça également, mais après avoir posté (grr ...).
Qu'en serait il avec le module Compress::Zlib ?
(en gardant un appel système pour le tar mais en remplaçant le gunzip)

Pour éviter le chargement du fichier en mémoire, il y a la méthode
'extract_archive'. De plus, Archive::Tar sait faire appel tout seul a IO::Zlib
(s'il est installé).

C'est vrai que c'est plus lent que 'tar' mais il faut comparer d'un côté :
(le temps d'extraction par Archive::Tar)
et de l'autre :
(le fork/exec pour lancer tar +
le temps d'extraction par tar)
Le temps de 'fork/exec' est loin d'être négligeable.

Cela dépend donc fortement de la taille des fichiers à traiter. Sur un petit
fichier, il faut passer par Archive::Tar. Sur un gros fichier, il faut passer
par 'tar'. Sur des tailles intermédiaires... il faut tester ;-)

Il faut aussi intégrer la décompression (qui a lieu avant l'extraction). Si le
tar externe sait faire la décompression (gnutar par exemple), ça peut jouer en
sa faveur.

Cela dépend aussi de comment vous utiliser vos outils. Faire :

gunzip file.tar.gz
tar xf file.tar

est moins efficace que :

gunzip -c file.tar.gz | tar xf -

qui est moins efficace que :

gnutar zxf file.tar.gz

En remplaçant un appel à system et mv (sic) par foreach et rename, le
script gagne effectivement en performance, et ceci sur un petit nombre
de fichiers.
Mais cela ne fait pas intervenir le chargement d'un module.

Le chargement d'un module est négligeable (quelques ms) si il y a un millier
de fichiers à traiter (quelques minutes ?).

Savez vous si le module Compress::Zlib traite indifféremment des
fichiers obtenus avec compress et avec gzip ?

Ne traite que gzip.

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>