La compression n'est que une fois, la mémoire utilisé pour la décompression ne peu dépasser la taille décompressé. Donc relativement modéré. Et pour le noyau c'est tout benef car ça compresse en xz tout les 15j une nouvelle version du noyau pour une grosse économie de bande passante pour tout le monde et les miroirs. La bande passante reste très chère dans la location de serveur.
Sur mon bench avec le noyau 3.3 64MB de mémoire utilisé pour la décompression, et 33% de réduction de taille avec -9 -e: http://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO
Bye,
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
# Gros gain
Posté par alpha_one_x86 (site web personnel) . En réponse à la dépêche Les nouvelles versions du noyau seront publiées en .xz. Évalué à 10.
Salut,
La compression n'est que une fois, la mémoire utilisé pour la décompression ne peu dépasser la taille décompressé. Donc relativement modéré. Et pour le noyau c'est tout benef car ça compresse en xz tout les 15j une nouvelle version du noyau pour une grosse économie de bande passante pour tout le monde et les miroirs. La bande passante reste très chère dans la location de serveur.
Sur mon bench avec le noyau 3.3 64MB de mémoire utilisé pour la décompression, et 33% de réduction de taille avec -9 -e:
http://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO
Bye,
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/