Si tu n'es pas informaticien, pour faire court, la méthode de compression utilisée par bzip2 prend plus de temps.
-- DINH V. Hoa,
"Paraît-il que c'est ce que recherchent la majorité des djeunz. Il n'y a plus aucun attrait pour les métiers scientifiques ni techniques. Ils veulent être chanteur, acteur ou fonctionnaire. C'est désépérant..." -- Emmanuel Delahaye
avec ant, je produis deux archives l'une en gz l'autre en bz2.
bz2, pour 100 kb de gagnés sur 8.8 mb est vraiment beaucoup plus long
(au moins dix fois)
Si tu n'es pas informaticien, pour faire court, la méthode de
compression utilisée par bzip2 prend plus de temps.
--
DINH V. Hoa,
"Paraît-il que c'est ce que recherchent la majorité des djeunz. Il n'y a plus
aucun attrait pour les métiers scientifiques ni techniques. Ils veulent être
chanteur, acteur ou fonctionnaire. C'est désépérant..." -- Emmanuel Delahaye
Si tu n'es pas informaticien, pour faire court, la méthode de compression utilisée par bzip2 prend plus de temps.
-- DINH V. Hoa,
"Paraît-il que c'est ce que recherchent la majorité des djeunz. Il n'y a plus aucun attrait pour les métiers scientifiques ni techniques. Ils veulent être chanteur, acteur ou fonctionnaire. C'est désépérant..." -- Emmanuel Delahaye
Si tu n'es pas informaticien, pour faire court, la méthode de compression utilisée par bzip2 prend plus de temps.
Merci, c'est ce que j'avais constaté ;-)
Bon, le problème vient peut-être du fait que je compresse des fichiers (archives *.jar) déjà compressés ?
J'ai envie de ne pas fournir la version bz2, pas grand intérêt dans ce cas ??? -- yt
Schmurtz
(Yvon Thoraval) wrote:
avec ant, je produis deux archives l'une en gz l'autre en bz2.
bz2, pour 100 kb de gagnés sur 8.8 mb est vraiment beaucoup plus long (au moins dix fois)
Tout d'abord, un petit rappel sur les principes de la compression. Pour comprimer un fichier, un logiciel de compression commence par rechercher les éléments redondants du fichier (des suites d'octets qui reviennent souvent par exemple).
Ensuite il réécrit le fichier en supprimant ces redondance, par exemple en remplaçant les chaînes d'octets redondante par un ID utilisant d'autant moins de bit que la chaîne en question est longue/fréquente. Les chaînes d'octets du fichier se répétant sont donc codés avec un code (l'id) beaucoup plus court. On stocke aussi la liste des chaînes ainsi codées afin de pouvoir revenir à la version non compressée (il suffit alors de remplacer les IDs par la chaîne correspondante.
La qualité d'un algorithme de compression réside dans sa capacité à trouver le plus de redondance possible, afin de pouvoir en supprimer un maximum. Plus on veux être efficace, plus il faut utiliser des algorithmes complexes, donc cela demande plus de temps. Sachant que pour chaque fichier il y a une limite théorique de compression que l'on ne peut pas atteindre, plus on veux s'en rapprocher, plus c'est difficile. Ainsi un gain fixe (gain de 100 octets par exemple) de compression coûtera d'autant plus cher qu'il permet de se rapprocher près de cette limite (et avec une croissance du coût exponentielle).
Pour faire un peu plus concret, je rappellerais que l'on peut préciser une efficacité de compression à gzip et bzip2 (avec les paramètres -1, rapide mais peu efficace, à -9, efficace mais lent). Ainsi, il est possible qu'en terme de taux de compression, un gzip -7 soit aussi efficace qu'un bzip2 -4 (pur supposition). Comme les valeurs par défaut sont -5 pour les deux commandes, le bzip2 semble avoir un mauvais rapport taux de compression/temps de calcul. Ce qui ne veux pas dire que le bzip2 est moins bon, il me semble même qu'il est meilleur (plus rapide) à taux de compression finale identique que le gzip.
avec ant, je produis deux archives l'une en gz l'autre en bz2.
bz2, pour 100 kb de gagnés sur 8.8 mb est vraiment beaucoup plus long
(au moins dix fois)
Tout d'abord, un petit rappel sur les principes de la compression. Pour
comprimer un fichier, un logiciel de compression commence par rechercher
les éléments redondants du fichier (des suites d'octets qui reviennent
souvent par exemple).
Ensuite il réécrit le fichier en supprimant ces redondance, par exemple
en remplaçant les chaînes d'octets redondante par un ID utilisant
d'autant moins de bit que la chaîne en question est longue/fréquente.
Les chaînes d'octets du fichier se répétant sont donc codés avec un code
(l'id) beaucoup plus court. On stocke aussi la liste des chaînes ainsi
codées afin de pouvoir revenir à la version non compressée (il suffit
alors de remplacer les IDs par la chaîne correspondante.
La qualité d'un algorithme de compression réside dans sa capacité à
trouver le plus de redondance possible, afin de pouvoir en supprimer un
maximum. Plus on veux être efficace, plus il faut utiliser des
algorithmes complexes, donc cela demande plus de temps. Sachant que pour
chaque fichier il y a une limite théorique de compression que l'on ne
peut pas atteindre, plus on veux s'en rapprocher, plus c'est difficile.
Ainsi un gain fixe (gain de 100 octets par exemple) de compression
coûtera d'autant plus cher qu'il permet de se rapprocher près de cette
limite (et avec une croissance du coût exponentielle).
Pour faire un peu plus concret, je rappellerais que l'on peut préciser
une efficacité de compression à gzip et bzip2 (avec les paramètres -1,
rapide mais peu efficace, à -9, efficace mais lent). Ainsi, il est
possible qu'en terme de taux de compression, un gzip -7 soit aussi
efficace qu'un bzip2 -4 (pur supposition). Comme les valeurs par défaut
sont -5 pour les deux commandes, le bzip2 semble avoir un mauvais
rapport taux de compression/temps de calcul. Ce qui ne veux pas dire que
le bzip2 est moins bon, il me semble même qu'il est meilleur (plus
rapide) à taux de compression finale identique que le gzip.
avec ant, je produis deux archives l'une en gz l'autre en bz2.
bz2, pour 100 kb de gagnés sur 8.8 mb est vraiment beaucoup plus long (au moins dix fois)
Tout d'abord, un petit rappel sur les principes de la compression. Pour comprimer un fichier, un logiciel de compression commence par rechercher les éléments redondants du fichier (des suites d'octets qui reviennent souvent par exemple).
Ensuite il réécrit le fichier en supprimant ces redondance, par exemple en remplaçant les chaînes d'octets redondante par un ID utilisant d'autant moins de bit que la chaîne en question est longue/fréquente. Les chaînes d'octets du fichier se répétant sont donc codés avec un code (l'id) beaucoup plus court. On stocke aussi la liste des chaînes ainsi codées afin de pouvoir revenir à la version non compressée (il suffit alors de remplacer les IDs par la chaîne correspondante.
La qualité d'un algorithme de compression réside dans sa capacité à trouver le plus de redondance possible, afin de pouvoir en supprimer un maximum. Plus on veux être efficace, plus il faut utiliser des algorithmes complexes, donc cela demande plus de temps. Sachant que pour chaque fichier il y a une limite théorique de compression que l'on ne peut pas atteindre, plus on veux s'en rapprocher, plus c'est difficile. Ainsi un gain fixe (gain de 100 octets par exemple) de compression coûtera d'autant plus cher qu'il permet de se rapprocher près de cette limite (et avec une croissance du coût exponentielle).
Pour faire un peu plus concret, je rappellerais que l'on peut préciser une efficacité de compression à gzip et bzip2 (avec les paramètres -1, rapide mais peu efficace, à -9, efficace mais lent). Ainsi, il est possible qu'en terme de taux de compression, un gzip -7 soit aussi efficace qu'un bzip2 -4 (pur supposition). Comme les valeurs par défaut sont -5 pour les deux commandes, le bzip2 semble avoir un mauvais rapport taux de compression/temps de calcul. Ce qui ne veux pas dire que le bzip2 est moins bon, il me semble même qu'il est meilleur (plus rapide) à taux de compression finale identique que le gzip.
Si tu n'es pas informaticien, pour faire court, la méthode de compression utilisée par bzip2 prend plus de temps.
Merci, c'est ce que j'avais constaté ;-)
Bon, le problème vient peut-être du fait que je compresse des fichiers (archives *.jar) déjà compressés ?
J'ai envie de ne pas fournir la version bz2, pas grand intérêt dans ce cas ???
Recompresser des fichiers déjà compresser n'est jamais bien utile... sauf le l'algorithme de première compression est mauvais (d'ailleurs dans ce dernier cas, mieux vaut compresser les fichiers directement avec le deuxième algorithme). En effet, une fois compressée, un fichier contient très peu de redondances, il est donc difficile de le compresser. C'est pareil pour les gens que s'amuse à zipper des vidéos, ça sert absoulement à rien, vu que la vidéo est déjà un fichier compressé.
Si tu n'es pas informaticien, pour faire court, la méthode de
compression utilisée par bzip2 prend plus de temps.
Merci, c'est ce que j'avais constaté ;-)
Bon, le problème vient peut-être du fait que je compresse des fichiers
(archives *.jar) déjà compressés ?
J'ai envie de ne pas fournir la version bz2, pas grand intérêt dans ce
cas ???
Recompresser des fichiers déjà compresser n'est jamais bien utile...
sauf le l'algorithme de première compression est mauvais (d'ailleurs
dans ce dernier cas, mieux vaut compresser les fichiers directement avec
le deuxième algorithme). En effet, une fois compressée, un fichier
contient très peu de redondances, il est donc difficile de le
compresser. C'est pareil pour les gens que s'amuse à zipper des vidéos,
ça sert absoulement à rien, vu que la vidéo est déjà un fichier
compressé.
Si tu n'es pas informaticien, pour faire court, la méthode de compression utilisée par bzip2 prend plus de temps.
Merci, c'est ce que j'avais constaté ;-)
Bon, le problème vient peut-être du fait que je compresse des fichiers (archives *.jar) déjà compressés ?
J'ai envie de ne pas fournir la version bz2, pas grand intérêt dans ce cas ???
Recompresser des fichiers déjà compresser n'est jamais bien utile... sauf le l'algorithme de première compression est mauvais (d'ailleurs dans ce dernier cas, mieux vaut compresser les fichiers directement avec le deuxième algorithme). En effet, une fois compressée, un fichier contient très peu de redondances, il est donc difficile de le compresser. C'est pareil pour les gens que s'amuse à zipper des vidéos, ça sert absoulement à rien, vu que la vidéo est déjà un fichier compressé.
-- Schmurtz
yvon.thoravalNO-SPAM
Schmurtz wrote:
En effet, une fois compressée, un fichier contient très peu de redondances, il est donc difficile de le compresser.
Ouais, c'est juste, enfin, là, pour la première compression, je n'ai pas le choix, je dois utiliser du jar (java oblige). -- yt
Schmurtz <moi@ici.com> wrote:
En effet, une fois compressée, un fichier
contient très peu de redondances, il est donc difficile de le
compresser.
Ouais, c'est juste, enfin, là, pour la première compression, je n'ai pas
le choix, je dois utiliser du jar (java oblige).
--
yt
j'avais pas, j'ai fait un truc "standard"... -- yt
ericb
Bonjour,
Ce qui ne veux pas dire que
le bzip2 est moins bon, il me semble même qu'il est meilleur (plus rapide) à taux de compression finale identique que le gzip.
Pour avoir un peu travaillé le sujet, on ne peut même pas démontrer qu'un algo est meilleur qu'un autre. Cela dépend des cas, et statistiquement, ça marche mieux avec gzip "dans certains cas" et pour bzip2 dans d'autres.
-- eric bachard French OpenOffice.org Community contributor (build of french releases for Linux PPC and Mac OS X / X11) See : <http://fr.openoffice.org>
Bonjour,
Ce qui ne veux pas dire que
le bzip2 est moins bon, il me semble même qu'il est meilleur (plus
rapide) à taux de compression finale identique que le gzip.
Pour avoir un peu travaillé le sujet, on ne peut même pas démontrer
qu'un algo est meilleur qu'un autre. Cela dépend des cas, et
statistiquement, ça marche mieux avec gzip "dans certains cas" et pour
bzip2 dans d'autres.
--
eric bachard <ericb@openoffice.org>
French OpenOffice.org Community contributor (build of french releases
for Linux PPC and Mac OS X / X11)
See : <http://fr.openoffice.org>
le bzip2 est moins bon, il me semble même qu'il est meilleur (plus rapide) à taux de compression finale identique que le gzip.
Pour avoir un peu travaillé le sujet, on ne peut même pas démontrer qu'un algo est meilleur qu'un autre. Cela dépend des cas, et statistiquement, ça marche mieux avec gzip "dans certains cas" et pour bzip2 dans d'autres.
-- eric bachard French OpenOffice.org Community contributor (build of french releases for Linux PPC and Mac OS X / X11) See : <http://fr.openoffice.org>
yvon.thoravalNO-SPAM
ericb wrote:
Pour avoir un peu travaillé le sujet, on ne peut même pas démontrer qu'un algo est meilleur qu'un autre. Cela dépend des cas, et statistiquement, ça marche mieux avec gzip "dans certains cas" et pour bzip2 dans d'autres.
mon expérience, très courte, sur des fichiers déjà compactés (jar standard de java je crois bien que l'algo est homologue à celui de zip) ets que bz2, fô oublier : - 1 - n'apporte pas de compaction supplémentaire intéressante (1%) ; - 2 - prend un temps fou. (dans les conditions pré-citées) -- yt
ericb <eric@b.org> wrote:
Pour avoir un peu travaillé le sujet, on ne peut même pas démontrer
qu'un algo est meilleur qu'un autre. Cela dépend des cas, et
statistiquement, ça marche mieux avec gzip "dans certains cas" et pour
bzip2 dans d'autres.
mon expérience, très courte, sur des fichiers déjà compactés (jar
standard de java je crois bien que l'algo est homologue à celui de zip)
ets que bz2, fô oublier :
- 1 - n'apporte pas de compaction supplémentaire intéressante (1%) ;
- 2 - prend un temps fou.
(dans les conditions pré-citées)
--
yt
Pour avoir un peu travaillé le sujet, on ne peut même pas démontrer qu'un algo est meilleur qu'un autre. Cela dépend des cas, et statistiquement, ça marche mieux avec gzip "dans certains cas" et pour bzip2 dans d'autres.
mon expérience, très courte, sur des fichiers déjà compactés (jar standard de java je crois bien que l'algo est homologue à celui de zip) ets que bz2, fô oublier : - 1 - n'apporte pas de compaction supplémentaire intéressante (1%) ; - 2 - prend un temps fou. (dans les conditions pré-citées) -- yt
