Benchmark: Imagens
Neste dataset, a nível de compressão, podemos ver vários escalões.
Do Zip ao Bzip2 anda pelos 94%. Do Xz ao 7zip, um pouco menos e de Rzip a Lrzip -Uz de 88 a 91%
No entanto, a nível de tempo a compactar, Xz a 7zip demora bastante tempo, mas o recordista, como seria de esperar é Lrzip -Uz.
Tendo em conta todos os factores, penso que o que ganha é Lrzip -g.
Se descontarmos o Lrzip -Uz, onde a máquina de testes não aguenta com a carga, Bzip2 e Xz não ficam bem na fotografia.
Por último, de notar que esperava maior compressão neste dataset, pois com ferramentas especificas, conseguiria reduzir bem mais o tamanho das imagens.
Mas estes são compressores genéricos e tem que se ter isso em conta.
Benchmark: Linux
Na pasta onde se encontram as diversas versões do kernel de Linux, consegue-se uma grande compressão, o que seria de esperar, devido aos ficheiros redundantes.
Mesmo assim, notam-se diferenças.
Num primeiro escalão temos as ferramentas baseadas em Zip, por volta de 22%. As outras, até ao Rzip, vão de 14 a 18%. Rzip fica-se pelos 9%, enquanto Lrzip, nos diferentes modos, vai de 1.24% a 6.69%.
É incrivel ver uma pasta de 9.8 GB, reduzida a pouco mais de 134 MB, mas isso tem um preço a nível de velocidade de compressão.
Somando os tempos aos dados, Lrzip -g e Lrzip -b saem vencedores e Xz e 7zip não impressionam.
Também de notar que a opção -U, no Lrzip, torna a compressão demasiado lenta e mesmo a descompressão.
Benchmark: Office 2007
Mais uma vez, temos 3 escalões bem definidos. De Zip a 7zip, fica-se pelos 90% aproximadamente. Rzip, um pouco melhor com 83 %.
Quem sai como grande vencedor, com uma vantagem enorme, para minha surpresa é Lrzip onde anda pelos 47% de redução do tamanho.
Tendo em conta os tempos, Lrzip -Ul sai vencedor. Mais uma vez, como esperado, Lrzip -Uz demora demasiado tempo nesta máquina.
Os que perdem são todos os outros.
Benchmark: Race (Videos h264)
Este benchmark já sabia que seria complicado de comprimir, mas fiquei admirado de comprimir tão pouco.
Houve mesmo casos em que o ficheiro comprimido é maior que o original.
Um ponto interessante é que o Xz foi o que conseguiu comprimir mais, o que pode significar que poderá fazer melhor figura noutro tipo de ficheiros que não os anteriores.
No entanto, devido à pouca compressão, é algo que não vale a pena tentar comprimir com um compressor genérico e quanto menos os tempos de compressão e descompressão, melhor.
Benchmark: Imagem virtual
Neste dataset temos resultados mais dispersos.
O Zip continua a ser o que comprime menos, mas o resto varia bastante. Penso no entanto que é de mencionar a opção lrzip -u como a melhor e que -Uz é impraticável nesta máquina.
Rar, Xz e 7zip demoram o mesmo ou mais tempo que parte das opções com Lrzip, mas nem sempre comprimem o mesmo.
Benchmark: Média de Compressão e total de tempos
Primeiro vamos olhar para as médias de compressão.
É claro ver que existe uma distinção algo grande entre todas as outras ferramentas de compressão e Lrzip.
É verdade que estou a efectuar benchmarks no seu ambiente. Ficheiros longos, mas mesmo assim a diferença é notável.
Também interessante é que conseguiu comprimir mais foi a opção lrzip -U, o que me diz que os defaults estão bem escolhidos, pois por default ele usa LZMA e o -U é de não limitar a memória na passagem por dicionário, o que pode ser inconveniente em muitos casos.
A nível de tempos de compressão lrzip -Uz é claramente a pior opção. Zpac é demasiado pesado para este computador e nota-se perfeitamente.
Xz, Rar e 7zip demoram demasiado tempo, o que é de estranhar quando Rar e 7zip são dos formatos mais utilizados e, pelo menos, 7zip é multithreaded em Linux.
Nestes dois casos os dois programas são duas betas e talvez isso contribua para esta situação.
A nível de descompressão, não há tantas diferenças, mas quando se usa -U na compressão em Lrzip, aumenta o tempo de descompressão.
Nos outros programas, os mais lentos são bzip2 e, mais uma vez, 7zip.
Conclusão
Penso que a primeira conclusão a tirar é que esta ferramenta, Lrzip, é algo de muito válido e pode ser muito útil, por ser multithreaded, usar bastante bem a memória RAM que a máquina possui, pelas boas taxas de compressão e a flexibilidade que nos permite, podendo estar ou não limitado pela memória na primeira passagem e poder usar vários algoritmos na segunda passagem.
Olhando para os resultados, nestes datasets e nesta máquina, a melhor solução é Lrzip, estando limitado na memória e usando gzip como método no segundo passo.
Mas é preciso frisar que é “nestes datasets e nesta máquina”, pois noutros datasets, apesar de pensar que Lrzip teria vantagem na mesma, outras opções podem ser melhores e zpaq, que é impossível de usar nesta máquina, escala a nível de performance e de taxas de compressão com o poder de processamento e tamanho da memória Ram.
Não se pode dizer que zpaq é inviável, pois o seu uso pode ser viável com uma melhor máquina ou com máquinas no futuro.
No roadmap da AMD para 2012 há processadores com 20 cores e servidores que têm muita memória RAM. Eu usei apenas 2 cores e 4 GB de Ram, com um disco de 5400 rotações.
É bom ver duas coisas. Primeiro, que processamento é sempre algo que não chega, por muito bom que o hardware seja num certo momento e que *nix está rodeado de pequenas pérolas, muitas vezes desconhecidas e que na prática melhoram certos aspectos relativos a computação.
Estranho um pouco os resultados do Rar, 7zip e Xz.
Xz está a ser vada vez mais usado e Rar e 7zip são dos formatos mais usados hoje em dia.
Não esperava estes resultados. Quase não têm lógica, porque no caso do 7zip eu vi pelo htop que ele é multithreaded.
Não sei se será da implementação dos aplicativos em Linux é o culpado ou se do formato. Talvez por serem versões beta.
Por último, espero que este artigo seja do agrado de quem o ler e se usarem *nix vos possa ser útil em relação a compressão de ficheiros.
