xz - la nuova compressione Slackware per i pacchetti

[Mario Vanoni]

Core 2 Dual 1866MHz, 4GB RAM, Slackware 12.2

comprimere dir 964MB/32 files
bzip2 4m34 > 801MB
xz 11m37 > 802MB
decomprimere la stessa
bzip2 3m42 > 964MB
xz 2m28 > 964MB

comprimere con find dir 1.2GB/48203 dirs/files
bzip2 7m34 > 788MB
xz 64m31 > 766MB (*)
decomprimere la stessa
bzip2 6m50 > 1.2GB
zx 4m42 > 1.2GB

compressione opzioni -9 -f
decompressione -d
find -type f -exec ...

(*) incredulo, rifatto due volte, tempi identici

[targzeta]

Bhè, se i dati sono questi, perchè si è passati da tgz a txz? Sembra solo più veloce durante la decompressione.
Ma lo hai eseguito con il paccketto xz della corrent o quello della slackware ufficiale?

Intanto per informazioni, l'elenco dei file presenti in un pacchetto, che nel formato tgz lo si può ottenere con:

Codice: Seleziona tutto

tar -ztf pacchetto.tgz

Con il nuovo formato lo si può ottenere mettendo in pipe:

Codice: Seleziona tutto

xz -dc pacchetto.txz | tar -t

Ovviamente valgono anche altre opzioni di tar,
Emanuele

[albatros]

Bhè, se i dati sono questi, perchè si è passati da tgz a txz? Sembra solo più veloce durante la decompressione.

Beh, la maggior parte delle persone i pacchetti li scompattano e basta, quindi, a parità di capacità di compressione, mi sembra ragionevole aver scelto xz al posto di bzip2 (e abbandonato gzip data la minor capacità di compressione).
E' vero però che su macchine datate il processo di installazione dei pacchetti potrebbe allungarsi notevolmente...

[targzeta]

...
Beh, la maggior parte delle persone i pacchetti li scompattano e basta, quindi, a parità di capacità di compressione, mi sembra ragionevole aver scelto xz al posto di bzip2 (e abbandonato gzip data la minor capacità di compressione)...

Sarebbe stato interessante avere i dati anche di gzip sugli stessi file.
Ma forse la scelta si è basata su altri criteri, nessuno ha trovato niente su internet?

Emanuele

[targzeta]

Trovato:

...first departure from the use of gzip for
compressing Slackware packages. Instead, we will be using xz, based on
the LZMA compression algorithm. xz offers better compression than even
bzip2, but still offers good extraction performance (about 3 times better
than bzip2 and not much slower than gzip in our testing). Since support
for bzip2 has long been requested, support for bzip2 and the original lzma
format has also been added (why not?), but this is purely in the interest
of completeness -- we think most people will probably want to use either
the original .tgz or the new .txz compression wrappers. The actual
Slackware package format (which consists of the layout within the package
envelope) has not changed, but this is the first support within Slackware's
package tools for using alternate compression algorithms.
Some people have asked why we don't pick a single extension, such as
.slk. While there's certainly a case to be made for that idea, the tools
would still need to support .tgz to handle older packages. Sticking with
".tgz" for everything makes no sense. Using extensions that reflect the
compression format used by the package envelope seems to be the most
transparent approach, and the one that best follows tradition.
As an example of the compression improvement with .txz, have a look
at the kernel-source package:
Before: kernel-source-2.6.29.2_smp-noarch-1.tgz (73808508 bytes)
After: kernel-source-2.6.29.2_smp-noarch-1.txz (49150104 bytes)
The size of the main package tree in /slackware has been reduced from
1.9GB to 1.4GB by converting most packages to .txz.
Most of the packages have been converted from .tgz to .txz, but we
will continue to make the gzip, pkgtools, slackpkg, tar, and xz packages
in .tgz format for the foreseeable future.
Enjoy! And thanks to Lasse Collin for the great work on xz.

Emanuele

[targzeta]

Ho fatto i test sul pacchetto citato.
gzip:

Codice: Seleziona tutto

time gzip kernel-source-2.6.29.2_smp-noarch-1.tar 

real    0m42.608s
user    0m40.770s
sys     0m0.920s

Codice: Seleziona tutto

stat kernel-source-2.6.29.2_smp-noarch-1.tar.gz 
  Size: 74479700        Blocks: 145614     IO Block: 4096   regular file

Codice: Seleziona tutto

time gunzip kernel-source-2.6.29.2_smp-noarch-1.tar.gz 

real    0m9.904s
user    0m6.700s
sys     0m1.060s

xz:

Codice: Seleziona tutto

 time xz kernel-source-2.6.29.2_smp-noarch-1.tar 

real    8m13.594s
user    8m6.290s
sys     0m2.170s

Codice: Seleziona tutto

stat kernel-source-2.6.29.2_smp-noarch-1.tar.xz 
  Size: 49150104        Blocks: 96093      IO Block: 4096   regular file

Codice: Seleziona tutto

 time xz -d kernel-source-2.6.29.2_smp-noarch-1.tar.xz 

real    0m15.013s
user    0m11.680s
sys     0m1.850s

bzip2:

Codice: Seleziona tutto

time bzip2 kernel-source-2.6.29.2_smp-noarch-1.tar 

real    1m54.522s
user    1m52.330s
sys     0m1.270s

Codice: Seleziona tutto

stat kernel-source-2.6.29.2_smp-noarch-1.tar.bz2 
  Size: 57805912        Blocks: 113014     IO Block: 4096   regular file

Codice: Seleziona tutto

time bunzip2 kernel-source-2.6.29.2_smp-noarch-1.tar.bz2 

real    0m25.105s
user    0m22.790s
sys     0m2.080s

Riassumendo:
Velocità di compressione:

1. gzip
2. bzip2 (+3 volte)
3. xz (+13 volte)

Dimensione del file:

1. xz
2. bzip2 (+1,2 volte)
3. gzip (+1,5 volte)

Velocità di decompressione:

1. gzip
2. xz (+1,7 volte)
3. bzip2 (+3,4 volte)

Ora la domanda è: "voi che avreste fatto?". Io mi sarei tenuto gzip .

Emanuele

[conraid]

Non ho statistiche adesso, se vuoi la prossima volta faccio delle prove, ma nella realizzazione dei pacchetti ho visto che per alcuni pacchetti si hanno miglioramenti notevoli.
inkscape è passato da 20mb a 10mb per esempio
ntop da 29 a 21
ma purtroppo sono anche cambiate le versioni quindi non è un test "vero"

ecco, questo è un esempio più vero in quanto ho solo cambiato gli slackbuild per aggiungere il suffiso per i 64bit, che naturamente essendo compilati su 32bit non è stato preso in considerazione

Codice: Seleziona tutto

$ ls -l
-rw-r--r-- 1 root root 12M 2009-04-08 16:44 digikam-0.10.0-i686-2cf.tgz
-rw-r--r-- 1 root root 7,6M 2009-05-24 18:33 digikam-0.10.0-i686-3cf.txz

Per bind invece ho cambiato solamente doinst.sh aggiungengo "-r /dev/urandom" come nella Slackware (che ha ancora bind 9.4.3)

Codice: Seleziona tutto

$ ls -l
-rw-r--r-- 1 root root 2,1M 2009-03-23 11:13 bind-9.6.0_P1-i686-4cf.tgz
-rw-r--r-- 1 root root 1,7M 2009-05-24 17:51 bind-9.6.0_P1-i686-5cf.txz

quindi i miglioramenti in termini di dimensione dei pacchetti ci sono eccome
Però ho trovato anche più lento l'estrazione, in alcuni casi notevolmente più letta

già che ci sono una prova veloce

Codice: Seleziona tutto

# time installpkg inkscape-r21290-i686-1cf.tgz
real    0m7.431s
user    0m4.994s
sys     0m1.909s

# time installpkg inkscape-r21383-i686-1cf.txz
real    0m11.792s
user    0m9.893s
sys     0m1.939s

p.s.
il mio ls è un alias a "ls --color=auto -Fh"

p.s.
ho tolto kipi-plugins perché avevo erroneamento confrontato versioni diverse

[Blizzard]

ciao,
ho notato che xz reagisce bene se si tratta di comprimere un mucchio di files piccoli.
Se sono grandi e pochi i test di Mario sono andati a perdere ad esempio.

Inoltre il tempo medio di compressione è tremendamente vasto.
Bisognerebbe fare una media dei tipi di pacchetti ad esempio presenti su slacky e vedere quanto tempo in più perderanno i pacchettizzatori ad ogni nuova release e soprattutto se questo influirà sul numero di pacchetti del repository.
In fin dei conti i pacchettizzatori passano un tempo "rilevante" sulla compressione dei pacchetti rispetto agli utenti finali che ne decomprimono un numero mediamente non eccessivo in un ciclo di distribuzione.

IMVHO tgz

ciao
Gio

[targzeta]

I risultati di conraid rispecchiano i miei sui sorgenti del kernel. Si vede che xz riesce a comprimere da 1,5 a quasi 2 volte in più rispetto a gzip. Ma non capisco perchè si è scelta la soluzione di diminuire la dimensione facendo aumentare il tempo di decompressione (e quindi installazione) ma soprattutto quello di compressione (13 volte di più sono una marea di tempo!!).

Mi chiedo se al giorno d'oggi non sia una scelta sbagliata, in fondo gli hard-disk così come la velocità di internet aumentano sempre di più.

Insomma, da quello che mostrano i test la scelta porta svantaggi sia ai pacchettizzatori (maggior tempo di compressione), sia a gli utenti finali (maggior tempo di decompressione). Gli unici a ricavarci vantaggi sembrano essere gli utenti che hanno una 56Kb.

Emanuele

[conraid]

I risultati di conraid rispecchiano i miei sui sorgenti del kernel. Si vede che xz riesce a comprimere da 1,5 a quasi 2 volte in più rispetto a gzip. Ma non capisco perchè si è scelta la soluzione di diminuire la dimensione facendo aumentare il tempo di decompressione (e quindi installazione) ma soprattutto quello di compressione (13 volte di più sono una marea di tempo!!).

per far entrare più cose in un dvd

[raffaele181188]

Beh, stesso discorso di sopra... C'è Internet, non serve a molto far entrare più cose in un DVD. Tra l'altro basterebbe togliere quell'infinità di pacchetti-doppione...

[conraid]

Beh, stesso discorso di sopra... C'è Internet, non serve a molto far entrare più cose in un DVD. Tra l'altro basterebbe togliere quell'infinità di pacchetti-doppione...

A parte che non ho scelto io la cosa
Ma forse sfugge che la banda si paga
Tenere un repository come slacky.eu per esempio ha comportato non poter inserire openoffice dato che bloccava tutto
Con slackers.it sforo la banda che mi hanno dato con i miei pochi e poco usati pacchetti

Per i pacchetti doppione, secondo me ne mancano anche alcuni di doppioni

[Mario Vanoni]

Core 2 Dual 1866MHz, 4GB RAM, Slackware64

1.3GB, 53087 dirs/files

xz -9 -f 51m53
xz -d 1m12

bzip2 -9 -f 4m6
bzip2 -d 2m3

niente altri test, rimetto la 12.2

[targzeta]

Certo che tu sei proprio un masochista Mario? Povero il tuo PC

Emanuele

[targzeta]

Non ho capito bene il discorso della banda. Io pensavo che uno avesse un tot di banda in upload, quindi se ci sono troppe connessioni (e una maggior quantità di roba da scaricare implica maggiori connessioni) la velocità si riduce per tutti, ma per questo esistono i mirrors.

Poi la Slackware non è mai stata una distribuzione nota per le sue dimensioni, ricordo che quando la Slackware stava su un CD c'erano già distro che stavano su uno e due DVD. Quindi presumo che questo problema lo hanno già affrontato altre distro.

Bho, non so, io rimango scettico verso questa decisione, "chi vivrà vedrà", diceva qualcuno,
Emanuele