bzip3
O bzip3, um compressor moderno inspirado na transformada de Burrows–Wheeler do bzip2, está chamando atenção por às vezes superar o zstd e outros formatos populares em razão de compressão, especialmente em certos conjuntos de dados altamente repetitivos. Comentadores destacam que suas vantagens dependem muito dos dados e dos parâmetros, apontam que alguns benchmarks publicados são enganosos (por exemplo, tamanhos de janela não correspondentes e uso enorme de memória) e observam forte sobrecarga de descompressão em alguns testes do mundo real. Também há debate sobre adoção prática — dado o forte suporte de ecossistema do zstd, as escolhas de licenciamento e nome do bzip3, e o fato de que muitos usuários agora priorizam descompressão rápida e com pouca memória em vez de ganhos marginais de tamanho.
Benchmarks e Equidade
- Vários comentaristas criticam os benchmarks oficiais por serem rudimentares e “cherry‑picked”.
- Principais preocupações:
- bzip3 é testado com blocos muito grandes (por exemplo, 512 MB), enquanto o zstd fica com janelas pequenas padrão (~8 MB), o que prejudica severamente o zstd em corpora repetitivos como árvores de código-fonte concatenadas.
- O uso de memória não é normalizado (por exemplo, casos com ~12–18 GB de RAM para bzip3 vs <1 GB para zstd).
- Algumas comparações omitem concorrentes fortes (zstd em testes do lrzip).
- Quando o zstd é executado novamente com uma janela longa correspondente (
--long), ele pode comprimir muito menor e mais rápido do que relatado, às vezes superando o bzip3 por margens grandes.
Desempenho no Mundo Real e Dependência dos Dados
- Vários testes independentes mostram comportamento altamente dependente dos dados:
- Em alguns arquivos, o bzip3 supera
zstd -19em razão, com velocidade comparável ou melhor. - Em outros, o zstd vence ligeiramente em tamanho e de forma decisiva em velocidade.
- Em alguns arquivos, o bzip3 supera
- Para uma árvore do kernel Linux, a descompressão do bzip3 foi relatada como ~145× mais lenta que o zstd multicore, com compressão ligeiramente pior.
- No corpus textual enwik9, o bzip3 compactou substancialmente menor que o zstd, mas usou ordens de magnitude mais RAM e tempo ao descompactar.
Uso de Recursos e Casos de Uso Práticos
- Um tema recorrente: o bzip3 pode alcançar razões impressionantes, mas a descompressão pode ser extremamente lenta e intensiva em memória, especialmente com blocos enormes.
- Alguns sugerem usá-lo apenas em cenários de “compactar uma vez, descompactar muitas vezes” após ajuste do algoritmo por arquivo.
- Outros concluem que ele “não é particularmente impressionante” em benchmarks agregados comparado a alternativas modernas.
Alternativas e Ecossistema
- O zstd é repetidamente descrito como o compressor de uso geral “padrão” da atualidade: muito ajustável, descompressão rápida, boas razões, amplo suporte (sistemas de arquivos, bancos de dados).
- Benchmarks em logs JSONL mostram o bzip3 oferecendo a melhor razão, mas com tempo de CPU muito maior; o zstd é quase tão pequeno quanto o gzip, mas vastamente mais rápido que os demais nos padrões padrão, com espaço para ajuste.
Confiabilidade, Licenciamento e Nome
- Um forte aviso de “os dados podem não ser recuperáveis” alarma alguns, mas outros observam que avisos idênticos existem no bzip2, xz e em licenças típicas de código aberto.
- Alguns não gostam de reutilizar o nome “bzip3” e da mudança para LGPL em vez da licença permissiva do bzip2; outros argumentam que tanto o nome quanto o licenciamento são prerrogativas do autor.
Direções Futuras
- Ideias levantadas: arquivos multi-stream que selecionem automaticamente algoritmos por região, otimização de parâmetros baseada em ML/agentes, e verificação formal da correção do compressor, embora esta última seja vista como muito difícil.