Compressão no Linux: o que vale a pena em 2026

📅 Qua, 4 dev 2026, 11:54 👤 Nerun

Em ago/2021, eu realizei dois testes de benchmark de compressores disponíveis no Linux Debian 11. Isso foi no Linuxers Noobs, quando o site ainda estava no Blogspot.^{[1] [2]} Os testes foram bons e honestos, mas, olhando hoje, havia algumas falhas metodológicas — apesar de os resultados baterem com os de outros artigos por aí.

O tempo passou, estamos em 2026, temos Debian Trixie/13, e decidi revisar a metodologia e repetir aqueles testes de forma mais precisa, excluindo formatos de nicho como ZPAQ e Brotli (voltados principalmente para uso server-side). Vamos ver no que deu?

Hardware

CPU: AMD Ryzen 5-5500, 6 cores, 12 threads (usado apenas 1 thread)
RAM: 32 GB, 4x Kingston Fury Beast, 8GB, 3200MHz, DDR4, CL16 (KF432C16BB/8)
Disco: Kingston, NVME M.2 2280, 1 Tb (SNV2S1000G)

Metodologia adotada

Primeiramente, o disco está formatado no sistema de arquivos BTRFS. Como ele possui Copy-on-Write (CoW), e isso poderia influenciar no resultado, optei por criar uma pasta de trabalho com CoW desativado (nodatacow). O atributo +C só afeta arquivos criados após sua aplicação, o que foi respeitado neste cenário.

$ mkdir testes
$ chattr +C testes
$ lsattr testes
---------------C------

Escolhi como dataset (a amostra de testes) o Kernel 6.18.8 (linux-6.18.8.tar.xz), porque é uma coleção de 1,5 GiB de arquivos de texto, que é onde os compressores brilham. Baixei diretamente na pasta, extraí tudo, então criei um novo tarball normalizado, sem compressão, para evitar variáveis inesperadas, por fim medi e registrei o tamanho em bytes, para maior precisão.

$ cd testes
$ wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.18.8.tar.xz
$ tar -xf linux-*.tar.xz
$ tar --sort=name \
    --mtime='UTC 1970-01-01' \
    --owner=0 --group=0 --numeric-owner \
    -cf kernel.tar linux-*/
$ stat -c '%s' kernel.tar
1608888320

Mas isso por si só não bastava. Era preciso garantir que nenhum compressor usasse a pasta /tmp do sistema ou outro lugar fora do diretório noCoW. Então para a execução dos testes criei uma pasta temporária dentro da pasta de trabalho.

$ mkdir tmp
$ export TMPDIR=$PWD/tmp
$ echo "$TMPDIR"
/home/daniel/Downloads/testes/tmp

O comando time deveria ser usado para medir uso de CPU e memória. Entretanto, o time embutido no shell tem várias limitações. Por isso, optei pelo GNU time v1.9, chamado explicitamente como /usr/bin/time, que fornece medições mais detalhadas e consistentes.

$ sudo apt show time
Package: time
Version: 1.9-0.4
Priority: optional
Section: utils
Maintainer: Bob Proulx <bob@proulx.com>
Installed-Size: 132 kB
Depends: libc6 (>= 2.34)
Homepage: https://www.gnu.org/software/time
Tag: devel::profiler, implemented-in::c, interface::commandline,
 role::program, scope::utility, suite::gnu, use::measuring,
 use::monitor, use::timekeeping, works-with::software:running
Download-Size: 47,7 kB
APT-Manual-Installed: yes
APT-Sources: https://deb.debian.org/debian testing/main amd64 Packages
Description: programa "time" do GNU para medição do uso de recursos da CPU
 O comando 'time' executa outro programa, então exibe informações sobre os
 recursos usados por aquele programa, coletados pelo sistema enquanto o
 programa estava sendo executado. Você pode selecionar que informação será
 relatada e em que formato, ou enviar para um arquivo ao invés de mandar
 para a tela.
 .
 Os recursos que o 'time' pode relatar ficam nas seguintes categorias
 gerais: tempo, memória, E/S e chamadas IPC.
 .
 A versão GNU pode formatar a saída em formas arbitrárias usando uma
 "string" de formatação estilo printf para incluir várias medições de
 recursos.
$ sudo apt install time

Por precaução extra decidi limpar o cache antes de cada teste individual (compactação, descompactação).

$ sync
$ echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null

Um detalhe importante é que alguns desses compressores não possuem multithreading nativo e, para realizar um teste comparativo sério dos algoritmos usados, todos deveriam ser testados em single thread. Pra isso usei o taskset.

/usr/bin/time -v taskset -c 0 <compressor e opções>

Para minha comodidade, criei uma alias temporária, concatenando limpeza de cache, uso do time, e aplicação forçada de single thread com o taskset:

$ alias testar="sync; echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null; /usr/bin/time -v taskset -c 0"

Testes

Os testes foram feitos usando a alias seguida do programa e opções: compacta-se, mede-se o tamanho do arquivo compactado, e extrai-se pra /dev/null para não sobrescrever o dataset.

$ testar gzip -k kernel.tar
$ stat -c "%s" kernel.tar.gz
$ testar gzip -d -c kernel.tar.gz > /dev/null

A medida de tempo usada é o User time (seconds), que mede o uso de CPU puro, ignorando espera de I/O e independente de scheduler. Já a memória usada foi a Maximum resident set size (kbytes) que é a memória de pico.

Todos os testes foram realizados no nível de compressão padrão dos compressores, a razão disso é que as pessoas raramente usam esses utilitários fora do padrão. E isso nos dará uma ideia realista dos benefícios reais do compressor para o usuário médio. Ademais, as posições obtidas nos resultados a seguir tendem a se manter independente do nível de compressão, com pequenas alterações.

Dataset

Arquivo: linux-6.18.8.tar.xz
Arquivo normalizado: kernel.tar
Tamanho do arquivo normalizado: 1.608.888.320 bytes

Resultados

Compressor	Nível (padrão)	Tempo (s) Compressão	Tempo (s) Descompressão	RAM pico (KB) Compressão	RAM pico (KB) Descompressão	Tamanho final	Rate
7z	mx=5	281,47	4,95	2.913.144	1.735.468	156.780.384	9,74%
xz	6	285,06	4,23	131.480	10.904	157.431.168	9,79%
lzip	6	326,44	10,75	1.554.060	512.556	163.718.027	10,18%
rar	m3	110,25	3,03	299.716	46.492	170.685.020	10,61%
bzip2	9	74,29	22,65	8.804	5.152	187.367.844	11,65%
zstd	3	4,67	1,07	71.912	7.692	230.037.466	14,30%
gzip	6	27,18	5,09	2.168	1.996	255.049.835	15,85%
zip	6	26,65	5,71	2.388	3.132	255.049.976	15,85%
arj	m1	43,79	6,97	2.228	1.984	256.635.649	15,95%
lz4	1	2,64	0,78	129.960	32.788	424.225.254	26,37%
lzop	3	2,25	2,17	2.324	2.004	439.824.936	27,34%

Resultados de testes fora do padrão

Compressor	Nível	Tempo (s) Compressão	Tempo (s) Descompressão	RAM pico (KB) Compressão	RAM pico (KB) Descompressão	Tamanho final	Rate
zstd	19	607,18	0,93	484.908	13.808	159.079.983	9,89%
zstd	18	360,64	0,93	381.336	13.960	163.040.267	10,13%
zstd	17	261,47	0,92	378.884	13.744	164.822.598	10,24%
zstd	14	103,24	0,93	270.080	9.888	182.955.226	11,37%

Conclusões

xz é um caso clássico de engenharia bem-feita: entrega compressão equivalente à do 7z, mas consome cerca de 22× menos RAM para compactar e mais de 160× menos para descompactar.
zstd assume com folga o posto antes ocupado por zip e gzip: compressão decente, absurdamente rápida e com custo de hardware baixo. Para uso geral moderno, virou o padrão de fato.
lzip é as Férias Frustradas (1983, Chevy Chase) dos compressores: não é mais rápido que 7z ou xz, comprime pior que ambos e ainda perde feio em uso de RAM para o xz. Serve, no máximo, como alternativa ao 7z nesse quesito. Mesmo o zstd no nível 17 supera o lzip no nível padrão (6): comprime em tempo semelhante ao xz, usa cerca de 3× mais RAM, mas descompacta aproximadamente 4× mais rápido, com consumo de memória parecido.
bzip2, gzip e zip são formatos superados. Ainda funcionam, claro, mas hoje só sobrevivem por inércia histórica. xz e zstd fazem tudo melhor.
rar, arj, lz4 e lzop são claramente legados. lz4 e lzop só fazem sentido quando velocidade absoluta é prioridade e espaço em disco é irrelevante. rar sobrevive basicamente em acervos antigos voltados ao Windows — e nunca conseguiu superar nem o onipresente (e terrível) zip em adoção.

Em suma, zstd e xz são o presente (não o futuro) da compactação de arquivos.

🔝