Benchmarks

A versão curta · medido em 23 de agosto de 2026 na linha de código que saiu como nzbfast 1.2.2

Nenhum cliente medido é mais barato em processador, memória e disco juntos

As rodadas mais recentes desta página correram em 23 e 24 de agosto de 2026 - a mais recente delas no próprio build de lançamento v1.2.2 - contra os builds atuais de outros quatro clientes no mesmo hardware, linhas e provedores: duas formas de trabalho de 6,5 a 87 GB, e taxas de linha de 250 Mbit a 10 GbE. Nessas rodadas nenhum cliente foi mais barato que o nzbfast em processador, memória e disco juntos: cada um custa mais em pelo menos dois dos três, o máximo que qualquer um deles economizou em qualquer eixo isolado foi cerca de 2 por cento - um empate estatístico, dentro da própria variação entre execuções desse cliente - e em disco cada um deles moveu pelo menos o dobro dos bytes para um resultado byte a byte idêntico. Como distribuído, o nzbfast também segurou a menor memória de todo cliente medido, em cada fixture, por 2,0x a 4,5x contra o rival mais próximo.

Qual desses é você?

A maioria dos downloaders escreve seu download no disco pelo menos duas vezes: uma enquanto baixa, outra enquanto desempacota. O nzbfast faz o trabalho inteiro em uma passagem única, então escreve cerca de metade dos bytes por trabalho, retém menos em memória enquanto trabalha, e gasta menos segundos de processador por GB. Isso é menos carga na máquina enquanto você a usa e metade das escritas por trabalho nos seus discos, para os mesmos arquivos byte a byte idênticos - e porque cada byte cruza o disco cerca de uma vez, seu disco só precisa acompanhar sua linha uma vez.

O nzbfast não vence toda tabela desta página, e as que perde estão em os legs que não vencemos - incluindo um desta mesma rodada. O que se manteve em toda rodada que medimos foi a conta combinada.

Metodologia primeiro

A configuração

• Clientes: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, cada tabela nos builds que ela nomeia. As rodadas mais recentes (23 de agosto de 2026) correram contra os builds então atuais do campo - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 e Weaver 0.7.8, seu binário distribuído mais recente, identidade provada por hash - contra a linha de código que foi lançada naquela noite como nzbfast 1.2.2, então o build que produziu os números novos é o mesmo que você pode baixar. Essas rodadas correram em uma máquina Apple Silicon de 20 núcleos em uma linha de 1 Gbit. Tabelas mais antigas mantêm os builds e máquinas contra os quais correram (máquinas Apple série M: "Europa" M1 Ultra em 10 GbE, "costa leste" M3 Ultra linha de ~2,4-3,0 Gbps) e dizem isso; elas subestimam o build distribuído em vez de favorecê-lo.
• Justiça: os mesmos provedores e TLS em todo lugar para cada cliente, legs corridos um atrás do outro intercalados. Cada concorrente ajustado ao seu melhor documentado: o SABnzbd recebeu pipelining_requests=8 (ele é distribuído com 1, ou seja, sem pipelining, e o ajuste vale porcentagens de dois dígitos em trabalhos grandes), o NZBGet recebeu ArticleCache/DirectWrite/DirectUnpack/ParQuick, o rustnzb sua configuração documentada. Desde 20 de agosto de 2026 cada rodada corre com cinco provedores em vez de seis - o número de provedores não é uma alavanca de throughput nessas máquinas, onde um único provedor sozinho já alcança o teto da linha, e um conjunto fixo mantém as rodadas comparáveis - então um número de seis provedores nesta página não é diretamente comparável com um número mais novo de cinco provedores, e cada tabela diz qual dos dois rodou.
• Estado final: um arquivo verificado, extraído, utilizável, não "download terminado". É isso que você realmente espera.
• Reprodutibilidade: cada afirmação é datada e medida da mesma forma: tempo decorrido + contadores de bytes da interface + pico de RSS da árvore de processos, resolução de 1-2 s. Onde um leg roda sobre um NZB publicado publicamente, nós o nomeamos para que você possa rodá-lo você mesmo.
• Notas de método que valem para a página inteira: o tempo de CPU é amostrado da árvore de processos a 2 Hz em cada braço de uma tabela e nunca colocado ao lado de um número de uma contagem diferente, porque os dois métodos discordam por definição. E/S de dispositivo é informada em GiB e bytes de rede em GB decimais; convertemos antes de dividir. E qualquer tabela que corre nosso próprio build contra nosso próprio build carrega um controle A/A - o mesmo binário correndo contra uma cópia byte a byte idêntica de si mesmo pelo mesmo harness - porque esse controle foi como pegamos nosso próprio harness de shootout dando um pênalti de ~1,5% para qualquer ferramenta que corresse primeiro (a história está ao lado das tabelas de extração abaixo). Dois braços e ordens trocadas não cancelam um viés que sempre recai sobre o primeiro braço; um controle A/A o expõe.

Linhas mais lentas · medido em 24 de agosto de 2026 no nzbfast 1.2.2

Quanto mais lenta a linha, menos a velocidade separa os clientes - e mais a conta separa

Em uma linha lenta o suficiente, o tempo de término de cada cliente é o fio da rede e nada mais, então uma linha lenta esconde muitos pecados. O que ela não consegue esconder é o que cada cliente queima para preenchê-la. Moldamos o equipamento de 1 Gbit para duas taxas que planos reais realmente têm e corremos os seis braços em cada uma - a mesma máquina, os mesmos cinco provedores, três repetições por cliente com a ordem alternada, cada leg verificado byte a byte, 36 de 36 corretos nas duas rodadas. O braço do nzbfast a 500 Mbit é o próprio build de lançamento v1.2.2.

Leia as duas tabelas como um gradiente. A 250 Mbit o campo inteiro fica dentro de 18% no relógio e lideramos o rival mais próximo por 4,4%; a 500 Mbit o intervalo abre para 14,7%; nas taxas de gigabit e 10 GbE nas tabelas acima e abaixo ele abre mais ainda. As diferenças de velocidade crescem com a linha. As colunas de recursos não esperam por uma linha rápida: em cada taxa medida, cada rival segurou pelo menos 3,9x a memória, gastou mais processador, e moveu cerca do dobro dos bytes de disco para o mesmo arquivo byte a byte idêntico.

O regulador de conexões se paga em linhas lentas, e o próprio contador de descartes do formatador de linha diz por quê. As predefinições de fábrica seguraram 25 conexões onde cada rival rodou centenas; o mesmo binário com o regulador desligado rodou 360. Menos fluxos por uma fila fixa significa menos perda e menos reenvio: o formatador registrou cerca de 4.200 descartes por leg limitado contra cerca de 155.000 sem limite a 500 Mbit, e o braço limitado foi mais rápido, 4,2x mais leve em memória e 1,3x mais leve em CPU que nossa própria postura de 360 sockets. Mais conexões não é mais velocidade; abaixo de um gigabit é mensuravelmente o oposto.

Medido em 24 de agosto de 2026, medianas de três, em uma máquina Apple Silicon de 20 núcleos com sua linha moldada para cada taxa (a taxa moldada verificada por uma sonda independente antes de cada rodada: 248 e 496 Mbit). O braço nzbfast de 500 Mbit é o build da tag de lançamento v1.2.2; a rodada de 250 Mbit rodou horas antes na mesma linha de código. Contagens de bytes em uma linha moldada são lidas do próprio contador de cada cliente, nunca da interface de rede (o formatador descarta e o TCP reenvia, então a interface conta as duas cópias). Os relógios são comparáveis dentro de cada tabela, não entre rodadas moldadas de formas diferentes. ¹ Os três legs do NZBGet a 500 Mbit variaram de 114-158 s com leituras de recursos estáveis - uma variação genuína, então a mediana é citada e a variação é declarada em vez de reduzida.

O post danificado · recorrido em 24 de agosto de 2026, cada build atual

Quando o post tem buracos: 6,5 GB com 60, 20 e 5 artigos mortos

Artigos expiram, servidores os descartam silenciosamente, uploads chegam incompletos - e o dano é onde a diferença entre clientes é maior, então ganha sua própria rodada no build mais novo de cada cliente, incluindo o nzbfast v1.2.2: máquina 10 GbE Europa, cinco provedores, 100 conexões por cliente, o mesmo release de 6,5 GB envenenado em três níveis de dano, três repetições por braço com a ordem alternada, cada leg verificado byte a byte contra o arquivo limpo. 63 de 65 legs voltaram byte a byte idênticos; os dois que não voltaram estão nomeados abaixo, porque são resultados.

Por que o post danificado é rápido aqui. Quando um artigo está faltando, um cliente normalmente pergunta ao próximo servidor, depois ao próximo, até que todo servidor tenha recusado - uma caminhada serial cujas recusas levam de dezenas de milissegundos a alguns segundos cada, durante a qual o download fica em zero. O nzbfast para de perguntar: assim que os dados de paridade já em mãos cobrem o que ainda está faltando, ele repara imediatamente em vez de terminar a caminhada. Essa é a segunda linha - o mesmo binário com esse comportamento desligado é de 1,4x a 2,3x mais lento dependendo do dano - e a rodada verificou que o mecanismo engatou em cada leg habilitado e nunca em um desabilitado. Contra o rival mais próximo a margem é de 2,4x a 2,7x, sem sobreposição em nenhum dos nove pares de repetição.

Disco é onde a margem é maior, e não é o truque do reparo. Cada braço que completou produziu o mesmo arquivo de 6,48 GB; o nosso moveu 6,2-6,8 GB de E/S de disco fazendo isso, o NZBGet 12,7-18,5 GB, o SABnzbd 13,9-20,3 GB e o rustnzb 12,8-13,1 GB. Isso é o pipeline de passagem única - a linha desligada move os mesmos 6,2 GB - então ele se mantém tanto em posts danificados quanto intactos.

¹ Os três legs do SABnzbd no dano mais pesado rodaram 43, 41 e 60 s - uma variação genuína em entradas idênticas, então a média é citada com o intervalo declarado. ² O rustnzb 1.4.5 entregou cada leg com bytes corretos, e seu custo está no tempo de processador e não na confiabilidade: cerca de 1.620 segundos de CPU contra um relógio de 107 s no dano mais pesado - cerca de quinze núcleos ocupados durante todo o leg - onde a mesma saída reparada nos custa cerca de 50 segundos de CPU. ³ O Weaver moveu 1,5 GB e 4,9 GB dos 6,5 dentro do nosso corte de 20 minutos nos dois níveis de dano mais pesados - o mesmo não-término nas três rodadas que já o correram, em três noites separadas. Nos 5 artigos mortos ele completou corretamente as três vezes. Seu custo de processador ali é sua própria história: cerca de 2.325 segundos de CPU para o leg de 194 s, contra os nossos 20.

Medido em 24 de agosto de 2026, todos os builds atuais: nzbfast v1.2.2 (a própria tag de lançamento), NZBGet 26.3-testing (build de 20 de agosto), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Um braço de continuidade correu o build do nzbfast da noite anterior dentro desta mesma rodada e caiu a menos de um segundo da v1.2.2 em cada fixture, então nada aqui depende de uma noite de sorte; e as configurações dos rivais diferem das da rodada anterior apenas no caminho do aplicativo, verificadas parâmetro por parâmetro antes de a rodada rodar.

Privado de RAM · medido em 24 de agosto de 2026 no nzbfast 1.2.2

A escada de pouca memória: 87 GB em ~0,3 GB de RAM

O mesmo trabalho de 87 GB da rodada acima, executado novamente com orçamentos fixos de memória de 2 GB, 1 GB e 256 MB - o que o dimensionador automático escolheria em uma máquina de 8 GB, uma de 4 GB, e um NAS de 2 GB. Cada leg produziu o arquivo idêntico verificado byte a byte, e a coluna de memória seguiu o orçamento, nunca o trabalho:

Um único leg por orçamento no build de lançamento, contido contra o mesmo checksum de saída da rodada de seis braços. O orçamento mais apertado custa cerca de 9% do relógio, e só porque essa linha é 10 GbE - blocos derramados custam tempo só quando a linha ultrapassa o disco, então em uma conexão doméstica típica um orçamento pequeno é praticamente de graça. A escada inteira, incluindo um download de 87 GB, cabe em 0,3-0,6 GB de memória; nas predefinições de fábrica o trabalho rodou em 286 MB. Nenhum outro cliente oferece um orçamento de memória rígido para o processo inteiro; o mais próximo disso são ajustes de tamanho de cache, e a rodada abaixo mede o que esses custam.

O limitador corrido contra os próprios ajustes do campo. No fixture de 34 GB (23 de agosto de 2026, máquina de 1 Gbit, cinco provedores, 30 de 30 legs com bytes corretos), limitar o NZBGet a um limite de cache equivalente mais que dobrou seu CPU (215,5 para 453,0 segundos de CPU, 2,10x) para comprar um corte de 52% em seu pico de memória, e o limite do SABnzbd foi quase de graça mas alcançou só parte de sua pegada. O ajuste de cache do rustnzb era decorativo no build corrido, e o Weaver não tem nenhum ajuste de memória, então os dois rodaram sem limite como colunas de referência em vez de serem avaliados em um orçamento que não conseguem manter. Nosso próprio lado dessa rodada foi superado pela escada v1.2.2 acima, que diz a mesma coisa a 2,5x o tamanho: o orçamento nunca é a restrição limitante, porque a passagem única já retém tão pouco de início.

Espaço livre · medido até o megabyte

Quão pouco espaço livre um trabalho precisa

Um cliente que escreve e depois desempacota precisa de espaço para os volumes do arquivo e o payload desempacotado ao mesmo tempo, então um trabalho não começa sem aproximadamente o dobro do download livre. A passagem única precisa do payload - e esta rodada mediu quanto a mais, encolhendo o volume de destino até cada cliente falhar. A resposta do nzbfast é uma constante de cerca de 50 MB de folga, não uma proporção, e ela se mantém de um trabalho de 6,5 GB a um de 34 GB.

Medido em uma máquina Apple Silicon de 20 núcleos, linha de 1 Gbit, cinco provedores, três repetições em cada limite, cada leg completado verificado byte a byte - as linhas rivais em 22-23 de agosto de 2026 (célula de 34 GB do Weaver repetida em 24 de agosto, nota 1), e a linha do nzbfast recortada de novo no build de lançamento v1.2.2 em 24 de agosto, que reproduziu os dois limites exatamente, 12 de 12 legs unânimes nos dois fixtures. Nossas células são um piso medido: o trabalho completa 3 de 3 com 48,6 MB e 51,0 MB de folga, e recusa 3 de 3 cerca de 17 MB abaixo disso - então o piso é real nas duas direções. O que o trabalho realmente retém se estabiliza na saída mais cerca de 3 MB; a folga paga pelos últimos momentos do pipeline, nunca por uma segunda cópia. As células dos rivais são seu piso medido no trabalho de 6,5 GB e uma suficiência confirmada na mesma proporção no de 34 GB (3 de 3 corretos byte a byte exatamente nessa proporção); não descemos a escada deles mais fundo no tamanho maior, então o piso real deles ali pode estar um pouco abaixo da proporção, e dizemos isso em vez de arredondar a nosso favor.

O que ficar sem espaço realmente parece importa tanto quanto o número. A 17 MB abaixo do seu piso o nzbfast bate na recusa do disco em uma escrita, para de forma limpa com "sem espaço em disco", mantém tudo o que chegou registrado em diário, e uma nova tentativa retoma sem baixar de novo - um parcial que você mantém, não um trabalho falho. ¹ A célula do fixture grande do Weaver foi resolvida por uma repetição em 24 de agosto: três de três legs corretos byte a byte na mesma proporção de ~2,25x, cada um mais rápido que o leg bom da primeira tentativa, com o espaço livre idêntico até o byte. Na primeira tentativa, em 23 de agosto, dois de seus três legs tinham travado a velocidades de um único dígito de MB/s com mais de 60 GB ainda livres e bateram no corte de 40 minutos da rodada. Essas travadas não voltaram, e a instrumentação de travamento da bancada estava ativa e silenciosa nos três legs da repetição, o que é uma medida positiva e não a ausência de uma. O que as causou continua desconhecido, e uma repetição limpa não é um diagnóstico: existem agora seis legs nessa proporção, quatro completos, e as duas falhas vêm de uma única janela de 80 minutos na primeira noite.

Publicações aninhadas · medido a 28 de agosto de 2026

Dez formas de embrulhar uma publicação, e quem chega mesmo ao ficheiro

Muito do que é publicado é deliberadamente difícil de abrir. O nome real do ficheiro está enterrado dentro de um segundo arquivo, por vezes um terceiro, por vezes num formato diferente em cada nível, para que a publicação revele o menos possível sobre o que contém. A isso junta-se o facto de as publicações chegarem danificadas: os artigos expiram, os envios chegam incompletos e os dados de recuperação têm de ser usados antes de se poder extrair fosse o que fosse. Um cliente percorre essa cadeia por si, ou entrega-lhe uma pasta de arquivos e para.

Construímos então dez formas que isolam exatamente isso, pusemos cada cliente atual à prova contra elas e depois fizemos o que as comparações costumam saltar: onde um cliente parou cedo, terminámos o trabalho à mão com as ferramentas habituais e cronometrámos isso também. Um cliente que desiste depressa parece rápido até se contar o trabalho que lhe deixa.

O nzbfast é o único que termina as dez sem ajuda. O NZBGet também chega ao ficheiro em todas as formas, mas precisa de 16 rondas de reparação e extração manuais em oito delas. O SABnzbd conclui cinco sem ajuda e duas ficam inalcançáveis mesmo à mão. O Weaver chega ao ficheiro em duas.

O padrão não é aleatório. As formas que o nzbfast percorre e as outras não são as embrulhadas e as danificadas: um arquivo dentro de um arquivo, uma mudança de formato a meio da cadeia, uma cadeia de cinco níveis e, sobretudo, um arquivo que chega corrompido com os seus próprios dados de recuperação ao lado. Nesta última, quatro clientes extraem o conjunto exterior na perfeição, entregam-lhe o arquivo defeituoso juntamente com o conjunto de recuperação que o repararia, e param.

Onde os clientes fazem o mesmo trabalho, a diferença não é pequena. Estas são as sete formas que os quatro clientes principais alcançam, contando a reparação manual de que cada um precisou:

Quatro a cinco vezes mais rápido, com menos de metade dos bytes escritos. O valor do disco é o que continua a contar depois da transferência: cada gigabyte dessa coluna é um gigabyte que o seu disco teve de absorver, e os clientes que usam uma zona intermédia escrevem o conteúdo, voltam a lê-lo e escrevem-no outra vez.

Onde não estamos à frente, e porque vale a pena dizê-lo. Em quatro das dez formas um concorrente escreve menos bytes do que o nzbfast durante a própria transferência. Em todos os casos é porque fez menos: na forma com arquivo interno corrompido, o NZBGet escreve 3,29 GB contra os nossos 4,65, e depois a sua passagem de reparação escreve mais 2,91, terminando em 6,20 GB contra os nossos 4,65. Nas restantes, o cliente que menos escreveu é um que nunca chegou ao ficheiro. Um número baixo de disco nem sempre é poupança.

Estes são testes de capacidade, não testes de velocidade. Os conteúdos são pequenos e servidos a partir da memória por uma ligação local, sem fornecedor nem rede pelo meio, por isso nada aqui é limitado pela velocidade de transferência e os segundos absolutos são muito mais curtos do que as mesmas formas levariam no mundo real. Se uma forma exige ou não trabalho manual é uma propriedade da forma e do cliente, e transfere-se diretamente. Os segundos comparam clientes a fazer trabalho idêntico, não preveem quanto demora uma tarefa real.

Os resultados completos por forma, o que é cada forma e o método estão na página de dados de arquivos aninhados.

Por que isso importa

Seu disco faz metade do trabalho

Armazenamento flash desgasta ao ser escrito. Um release de 94 GB custa ao seu disco cerca de 90 GB de escrita sob o nzbfast; sob um cliente que faz estágio e desempacota, o mesmo release custa aproximadamente o dobro. Em um NAS com discos rígidos a forma de passagem única também remove a longa passagem de thread única no final de cada download criptografado - uma pausa medida em 20 segundos em uma estação de trabalho rápida de 32 núcleos com destrancamento acelerado por hardware, e correspondentemente mais longa nas máquinas de baixa potência que a maioria das pessoas realmente usa para isso. Citamos o número pequeno porque é o que medimos.

Shootouts de componentes

Os benchmarks mais técnicos, para quem gosta de mais dados

Reparo (PAR2) e desempacotamento (RAR) são código nativo nosso e não binários de terceiros empacotados, então também os corremos de forma independente contra as ferramentas dedicadas em corpora idênticos, em quatro máquinas cobrindo o que um leitor poderia realmente possuir. Um tempo só conta quando a saída é byte a byte idêntica ao payload de origem: cada número de RAR abaixo foi verificado com sha256 contra a origem, e cada arquivo reparado contra o conjunto pristino.

Extração RAR: 7 formas de arquivo, 6 ferramentas

A rodada anterior desta tabela usava de 100 MB a 200 MB por forma, o que foi um erro: cerca de 28 ms de lançamento de processo eram 40% do leg de armazenamento, e a ordenação que isso produziu não se sustenta em um tamanho realista. Esta rodada usa 1 GB de payload por forma, e isso muda várias respostas, incluindo algumas na direção contrária. Os arquivos são criados com o rar 7.23 oficial, então nenhuma ferramenta é julgada com entrada do seu próprio codificador, e os mesmos bytes são corridos em cada máquina.

O que está no payload importa mais do que parece. Um payload construído com cópias de blocos torna cada forma comprimida um benchmark de cópia de memória; um payload de texto puro torna isso um benchmark de literal-e-Huffman; medimos os dois e eles não concordam sobre quem vence. Então as quatro formas comprimidas usam terços iguais de texto, registros estruturados e bytes incompressíveis, e as duas formas nos extremos dessa faixa são legs separados de propósito: store é incompressível e repetitive é quase tudo correspondências. O construtor e o harness estão no repositório, então o corpus pode ser reconstruído byte a byte.

Recorrido em 23 de agosto de 2026 no motor 1.2.2, e a varredura se mantém. As três ferramentas que um leitor mais frequentemente considera - a nossa, unrar 7.23 e rarpar 0.2.5 - foram recorridas no desktop de 32 núcleos no motor de lançamento (o código de extração corrido é byte a byte idêntico à tag 1.2.2), seis rodadas intercaladas, mínimo por ferramenta, a saída de cada leg verificada contra o manifesto do payload. Segundos, quanto menor melhor:

Todas as sete formas nossas, na mínima e na mediana, de 1,16x a 4,29x contra o unrar. Esses tempos não são comparáveis célula a célula com a tabela mais ampla abaixo - o harness foi revisado desde as rodadas dessa tabela e o número de rodadas difere - então leia cada tabela contra si mesma. A tabela mais ampla mantém suas próprias datas e seu campo de seis ferramentas, e sua coluna nzbfast descreve o motor que a 1.2.2 distribui: a nova corrida acima mediu o motor atual nivelado com o build daquela tabela nas sete formas, resolvido por contagens de instruções de hardware (0,14% menos para o mesmo relógio), então essas células não são os números de um build superado usando um rótulo atual. Esta nova corrida é também onde a regra A/A na seção de configuração foi conquistada. Uma passagem no mesmo dia primeiro relatou uma forma como uma pequena regressão contra nosso próprio build anterior, e a leitura sobreviveu rodando as duas ordens de braço. Um controle A/A - o mesmo binário corrido contra uma cópia byte a byte idêntica de si mesmo - mostrou o harness dando a quem quer que corresse primeiro um pênalti de cerca de 1,5%: o binário idêntico venceu só 6 das 15 rodadas na primeira posição, e trocar as ordens não cancela um viés que sempre recai sobre quem está primeiro. Contagens de instruções de hardware resolveram a questão que o harness não conseguia - o build mais novo aposenta 0,14% menos instruções para o mesmo relógio, então não houve regressão. Cada comparação de nosso build contra nosso build que publicamos agora carrega esse controle.

O campo inteiro, segundos, quanto menor melhor. Melhor de três, ferramentas intercaladas dentro de cada rodada em vez de corridas em blocos, saída verificada contra o payload de origem em cada execução isolada. Uma ferramenta que produziu os bytes errados recebe uma nota de correção, nunca um tempo rápido. rarpar é o código próprio de RAR e PAR2 do Weaver, construído a partir do código-fonte em bd87611; fixamos o commit em vez de uma versão porque suas crates carregam três números de versão diferentes.

Onde o campo não conseguiu competir, e por quê. ¹ O 7-Zip corrido aqui é o pacote Homebrew, que recusa toda forma comprimida com ERROR: Unsupported Method e só lê a forma armazenada no macOS. Uma versão anterior desta página atribuiu isso ao build do 7-Zip para macOS, o que estava errado: o Homebrew o compila sem o codec unRAR não livre, enquanto o build de macOS que a 7-zip.org distribui carrega o codec e decodifica as sete formas, como o build do Windows faz. Remedido em 14 de agosto de 2026. Se você instala o 7-Zip a partir do projeto em vez do Homebrew, esta coluna não descreve o que você tem. ² O bsdtar não tem suporte a múltiplos volumes RAR5 e produziu um arquivo truncado sem relatar erro, então esse leg é uma falha de correção e não um tempo lento; nosso harness capturou isso verificando a saída, o que é por que vale a pena verificar a saída. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ o unar não distribui ferramenta de linha de comando para Windows, então o campo do laptop é cinco. ⁶ O grupo M5 Max corre as três ferramentas que um leitor de macOS realmente buscaria - unrar, rarpar e nós; unar, bsdtar e 7-Zip não foram corridos nessa máquina. O unrar dela é o 7.22, o build mais novo que roda sem supervisão ali.

Cada forma em cada máquina exceto uma, e essa é um empate. As formas de correspondência curta se resumem a duas coisas específicas em nosso decodificador. Uma correspondência de dois a trinta e dois bytes costumava pagar por uma chamada completa à rotina de cópia de memória da plataforma, e a chamada custava mais que a cópia; copiar trinta e dois bytes fixos por meio de um registrador em vez disso é por que repetitive, solid e o dicionário de 128 MiB - as três formas construídas com correspondências curtas - são todas rápidas de uma vez. E o checksum roda a jusante da thread do escritor em vez de nela. A única célula que não vencemos de forma clara é a forma armazenada no desktop de 32 núcleos, onde o unrar e nós ficamos a três milissegundos de diferença em um leg que é puramente mover bytes - idêntico na precisão desta tabela, então as duas células são marcadas e isso é pontuado como empate, não como derrota e não como vitória.

A forma que vencemos por mais margem é a que a usenet realmente publica às centenas de cada vez: 400 arquivos pequenos, 4,3× e 4,4× contra o unrar e 5,4× a 5,5× contra o rarpar. Isso é paralelismo por membro, e é a diferença entre um extrator escrito para uma fila de download e um escrito para uma linha de comando. A forma armazenada, que o censo acima diz ser 84% dos bytes na rede, é um quase empate para as três ferramentas sérias, porque nesse ponto todo mundo está só movendo bytes.

Uma escolha que vale a pena declarar. Os arquivos são empacotados com o compressor fixado em quatro threads. Sem isso, a divisão de blocos do RAR segue o número de núcleos de qualquer máquina que empacotou o arquivo, então um desktop de 32 núcleos e um de 20 núcleos produzem bytes diferentes a partir da mesma entrada e as máquinas deixam de ser comparáveis. Fixar isso torna o corpus de extração byte a byte idêntico em todo lugar, que é o objetivo, mas também limita quanto da decodificação pode rodar em paralelo - então quando as duas formas mais próximas eram derrotas, nós as recorremos contra arquivos empacotados com todas as 32 threads, para verificar que a fixação não era a causa. Não era: solid foi de 4,2% atrás para 2,4% atrás e o dicionário de 128 MiB de 6,6% para 6,3%, a mesma ordem de qualquer forma. Ambas agora são vitórias no corpus fixado por uma margem mais ampla do que essa verificação poderia explicar.

Por que não há linha RAR4, e o que acontece a esses posts. Cada forma acima é RAR5 ou RAR7, que é o que a usenet publica hoje. Arquivos RAR4 mais antigos ainda aparecem, e o mesmo motor os lê, incluindo as formas comprimidas e protegidas por senha, na mesma passagem única que os mais recentes em vez de escrever os volumes no disco e desempacotá-los depois. Eles não têm linha aqui porque o rar 7.23 oficial não consegue mais criar RAR4, então não existe um corpus neutro para correr o campo; esse trabalho é verificado contra arquivos escritos pelo WinRAR 3.00, byte a byte contra o unrar.

Verificação e reparo PAR2: conjunto de 1 GiB, quatro níveis de dano

Corpus: 1 GiB de payload aleatório empacotado em modo armazenado em 21 volumes RAR, depois dois conjuntos PAR2 a 10% de redundância, um com blocos de 1 MiB e um com 64 KiB, depois mapas de dano fixos. Cada execução usa o mesmo protocolo: cópia nova, ler o corpus inteiro uma vez para aquecer o cache, depois cronometrar. Melhor de três rodadas intercaladas; cada volume reparado é comparado com o conjunto pristino em cada rodada. Quanto menor melhor.

Uma correção sobre o corpus, porque uma versão anterior desta página exagerou isso. Dissemos que cada máquina corria um corpus byte a byte idêntico, verificado por hash. Fazer o hash de cada volume de cada conjunto mostra que isso é verdade para o desktop de 32 núcleos e o laptop Windows, que coincidem exatamente, e não para o desktop de 20 núcleos, que tem um sorteio aleatório diferente da mesma forma: os mesmos 21 volumes nos mesmos tamanhos, os mesmos dois tamanhos de bloco, e o dano verificado nos mesmos 3, 101 e 1.500 blocos espalhados pelo mesmo número de arquivos. Cada número dentro de uma linha ainda é medido em bytes que cada ferramenta naquela linha compartilha, que é no que cada comparação se apoia. Mas as linhas não são quatro visões de uma entrada, e como o caráter do payload vale cerca de 7% para uma ferramenta concorrente na varredura, isso vale a pena declarar em vez de disfarçar.

Qual par2 é qual. O par2cmdline original é a implementação de referência da qual todo mundo fez fork. O par2cmdline-turbo é o fork que traz embutido os kernels SIMD de Galois escritos à mão do ParPar: é exatamente isso que "turbo" significa, e é por isso que o turbo, e não o original, é a ferramenta que vale a pena medir. As duas colunas turbo abaixo rodam esses mesmos kernels ParPar. O que as separa não é a aritmética mas o build e os parâmetros.

Confirmado no build distribuído contra o rival atual, 24 de agosto de 2026. Essas tabelas foram medidas antes de a 1.2.2 ser lançada e antes de o par2cmdline-turbo lançar a 1.5.0 (20 de agosto de 2026), então a coluna de 20 núcleos foi recorrida nos dois: nosso build de lançamento 1.2.2 contra o turbo 1.5.0, três rodadas intercaladas por leg, cada arquivo reparado comparado com o conjunto pristino. Os quatro legs se reproduzem - o nosso 0,18 / 0,30 / 0,75 / 2,02 contra o 0,19 / 0,33 / 0,74 / 2,07 impresso aqui, e o turbo 1.5.0 fica dentro de poucos por cento do build da tabela em cada leg e nas duas configurações. As células permanecem como publicadas; as outras três máquinas mantêm suas próprias datas.

Então a concorrência aparece duas vezes, e uma dessas colunas é o melhor caso dela e não o padrão. O binário distribuído que você baixaria é compilado para uma CPU genérica de referência e faz hash de só alguns arquivos por vez; compilar o mesmo código-fonte para a CPU real da máquina e passar -T16 deixa usar as instruções que essa máquina realmente tem e fazer hash de dezesseis arquivos de uma vez. No laptop isso vale até 2,6x, inteiramente do build e dos parâmetros. Julgue-nos pela coluna ajustada, que é a comparação mais difícil; a coluna distribuída é o que alguém que baixa o programa realmente experimenta. par2cmdline é o original, versão 1.2.0, compilado a partir do código-fonte em cada máquina. rarpar é a implementação própria de PAR2 do Weaver, compilada a partir do código-fonte com seu backend Metal de GPU habilitado. O par2j do MultiPar é exclusivo do Windows, então aparece só nas linhas do laptop Windows. As linhas do M5 Max correm as duas ferramentas com builds atuais de macOS arm64 ao lado das duas colunas turbo; o par2cmdline clássico não foi corrido nessa máquina.

Todas as dezesseis células do nzbfast - quatro máquinas em quatro níveis de dano - são nossas, várias por mais de 2× contra o build ajustado e por 2,3× a 7,7× contra o que você realmente baixaria. As células de dano pesado são as interessantes, e a nota abaixo explica o algoritmo por trás delas.

O original está de volta na tabela, e vale a pena ver por que o fork existe. Uma versão anterior desta página tirou a coluna par2cmdline com o argumento de que era mais lento que tudo o mais na rodada, o que é verdade e não é motivo suficiente: é a implementação da qual quase toda outra ferramenta descende, e os leitores merecem a referência em vez da nossa afirmação sobre ela. No nível de dano mais pesado ele leva cerca de 69 s onde o fork SIMD leva 3,2 s e nós levamos 3,1 s. Esse fator de vinte é o argumento inteiro para os kernels de Galois escritos à mão, e é o mesmo argumento que fazemos pelos nossos.

Dano leve é o caso que importa. Um punhado de artigos falhos é muito mais comum que 101 blocos mortos, e nada como 1.500. A maior parte de um reparo leve não é a matemática de Reed-Solomon de jeito nenhum, é ler e fazer MD5 de um gigabyte, o que é por que a linha de 3 blocos acompanha a linha de verificação limpa em vez das linhas de reparo.

O nível de dano mais pesado é um tipo diferente de trabalho, e recebe um algoritmo diferente. Aquele último nível danifica 1.500 blocos em todos os 21 volumes e consome cerca de 91% dos dados de recuperação, onde a aritmética de Reed-Solomon, e não o hash ou o disco, se torna quase todo o trabalho. O build distribuído calcula os reparos mais pesados com uma transformada numérico-teórica em vez da dobra clássica de campo de Galois - a mesma matemática, avaliada em uma forma que escala muito melhor em contagens altas de blocos: 2,7× à frente do build ajustado no desktop de 20 núcleos, e no laptop Windows 2,7× à frente do build ajustado e 2,2× à frente do MultiPar. Dano leve ainda roda o caminho clássico, o que é por que os outros níveis quase não se moveram: a transformada só se paga acima de cerca de 512 blocos danificados, então abaixo disso o despachante não a usa.

Um caminho mais rápido só vale a pena se não puder estar errado. Os dois caminhos calculam a mesma quantidade e são idênticos bit a bit por construção, e cada reparo nesta página foi condicionado a que os arquivos reconstruídos batessem com o conjunto pristino: 228 reparos cronometrados nas máquinas desta rodada, zero divergências. O build distribuído não depende só desse histórico. Cada reparo verifica sua própria saída contra os hashes dos arquivos, e um que falhasse seria refeito com o caminho clássico automaticamente, registraria a divergência, e manteria o caminho clássico pelo resto daquela execução. O ajuste está no painel como modo PAR rápido se você preferir não usá-lo de jeito nenhum, e máquinas com pouca memória para isso o recusam sozinhas em vez de tentar e falhar. Remedido em 2 de agosto no build atual: os dois desktops ficam a poucos por cento desta tabela, e com o modo PAR rápido desligado o desktop de 20 núcleos volta a exatamente o tempo mais lento do caminho clássico, o que diz que a vitória é o método e não as condições.

A coluna do laptop Windows precisou de uma correção, e ela vai contra nós. O Windows rebaixa trabalho contínuo em segundo plano para os núcleos de eficiência depois de alguns segundos. Nosso daemon opta por sair disso na inicialização e nenhuma das outras ferramentas consegue, então uma versão anterior desta página publicou os tempos limitados delas como se fossem os tempos próprios das ferramentas. Rodar de novo essa máquina com cada ferramenta elevada a prioridade alta move o campo inteiro: no nível de dano mais pesado o par2-turbo vai de 22,4 s para 6,41 e o rarpar de 59,2 s para 14,4, e para um corte desta página isso transformou a coluna de nossa vitória em uma que perdemos. A coluna do laptop inteira é medida assim agora - a correção permanece mesmo que a linha tenha sido reconquistada pela mudança de algoritmo acima, porque os tempos do campo naquela máquina só são honestos com o limitador removido.

Registros de recuperação RAR: reparando sem PAR2

Quando o PAR2 não consegue cobrir o dano, o registro de recuperação dentro do próprio RAR é a última linha de defesa. Até a 1.0.8 o nosso falhava em qualquer arquivo acima de cerca de 13 MB, então esse leg não podia rodar de jeito nenhum. O dano é três buracos de 3.000 bytes a 20%, 50% e 80% da região protegida. As duas ferramentas produziram saída byte a byte idêntica ao arquivo pristino, e a nossa é byte a byte idêntica ao que o próprio rar r escreve. Melhor de três, desktop de 32 núcleos, as duas ferramentas recorridas juntas em 2 de agosto.

Uma versão anterior desta página mostrava o tamanho de 512 MB como uma derrota, e explicava isso como o preço de percorrer o volume em pedaços em vez de segurar tudo em memória. Essa explicação estava correta na época e agora está obsoleta: o custo era um CRC64 bit a bit no caminho de reparo, substituído por um baseado em tabela, e a derrota foi junto. Não há mais um cruzamento, e o conjunto de trabalho limitado foi mantido. O tamanho de 2 GB está aqui porque os volumes que um daemon realmente encontra vão de 8 GB a 20 GB, não 512 MB, e um leg que para abaixo da faixa real não é muito de um teste.

O que mudou este corte, e o controle que confirma isso. Encontrar quais blocos estão danificados tinha se tornado a maior fase deste reparo - maior que a própria aritmética de reparo - e rodava em uma única thread, lendo 64 KB de cada grupo pelo arquivo, uma vez por grupo. Agora faz uma única passagem sequencial em ordem de arquivo com os checksums por fragmento calculados em paralelo, e o volume reparado é clonado em vez de copiado onde o sistema de arquivos consegue fazer isso. A detecção sozinha caiu de cerca de 300 ms para 18 ms no arquivo de 512 MB, o que é a maior parte do que mudou acima. O controle é a coluna ao lado da nossa: o rar r foi recorrido nas mesmas rodadas na mesma máquina e voltou a poucos por cento de seus tempos anteriores, então a mudança no intervalo é nossa e não do benchmark.

O M5 Max repete o padrão, corrido em 31 de julho com o mesmo corpus e os mesmos filtros: 0,050 / 0,066 / 0,171 / 0,581 s contra os 0,211 / 0,335 / 0,751 / 1,735 do rar r nos tamanhos de 16 MB a 512 MB - 3,0× a 5,1× mais rápido; o tamanho de 2 GB não foi corrido nessa máquina. Esses números são anteriores à reescrita de detecção descrita acima, então são de um build mais antigo, mantidos aqui como a segunda máquina em vez de como um número atual.

O rarpar do Weaver está ausente desta tabela sozinha, e não por escolha: ele não implementa esse reparo. Pedido para consertar um desses arquivos ele responde "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", e deixa o arquivo danificado. Ele aparece em toda outra comparação nesta página: os quatro legs de PAR2 acima, as sete formas de extração acima disso, e o leg de volumes de recuperação logo abaixo, que é o trabalho que ele diz que faz - e que ele vence.

Volumes de recuperação: reconstruindo arquivos .rev ausentes por inteiro

A outra metade da própria história de recuperação do RAR, e até esta rodada a maior derrota desta página. Um arquivo .rev é um volume de recuperação independente: três deles ao lado de um conjunto de 21 volumes conseguem reconstruir quaisquer três volumes que nunca chegaram. Corpus: 1 GiB armazenado em 21 volumes de 50 MB com rar rv3, depois os volumes 4, 11 e 19 apagados - três perdidos contra três volumes de recuperação, que é o pior caso que o conjunto ainda consegue sobreviver. Melhor de três, cada volume reconstruído comparado com o pristino.

A célula de 32 núcleos aqui era 3,12 s contra os 0,47 do rar rc no corte anterior desta página, publicada como 6,6× mais lenta e o pior número nela. A causa era a resolução de apagamento rodando a cerca de 48 MB/s de saída reconstruída onde a RARLab administrava 320; agora roda na mesma aritmética baseada em tabela do resto do código de recuperação, o que é uma melhoria de sete vezes e transforma a derrota em vitória nas duas máquinas. As margens são 3% e 14%, então é uma vitória para declarar com clareza e não para destacar como manchete, e o motivo de ser declarada de jeito nenhum é que a derrota foi declarada primeiro.

Este leg existe porque o rarpar do Weaver implementa exatamente isso e pediu para ser medido nisso. Estava vencendo com folga quando o publicamos pela primeira vez, e o publicamos naquela época por esse motivo.

A correspondência de arquivos nunca foi o custo, o que vale a pena registrar porque era o suspeito intuitivo: volumes de recuperação não carregam nomes de arquivo, então identificamos quais posições sobreviveram fazendo o checksum de cada volume em disco em vez de confiar em como são chamados, e contra um conjunto intacto, onde a correspondência é tudo que acontece, a passagem inteira leva 0,18 s.

O que mais mudou, e onde isso não aparece. Duas outras mudanças de motor entraram que esses corpora não conseguem ver, listadas aqui para que os números acima não sejam lidos como a história inteira: arquivos RAR5 com dezenas de milhares de membros resolvem cada membro uma vez em vez de percorrer a lista por worker, o que é 3× menos tempo de processador em 40.000 membros; e o leitor de bits do RAR1.3 trabalha uma palavra por vez, o que é 2×. Nenhum dos dois aparece acima, porque as formas aqui têm 400 membros e nenhum RAR1.3.

O que deliberadamente não fazemos: nunca criamos PAR2. Um downloader não tem motivo para isso, e o ParPar é dono desse leg. Também compramos velocidade com memória nos dois motores: a extração atinge um pico de cerca de 240 MB contra os 41 MB do unrar, e a verificação cerca de 126 MB contra os 7 MB do turbo, porque esses são os motores embutidos que acompanham um download ao vivo em vez de execuções únicas independentes. A forma de dicionário de 128 MiB é o pior caso disso, com cerca de 304 MB contra os 139 MB do unrar. O reparo mais pesado agora também custa memória: o método mais rápido para 512 ou mais blocos ausentes trabalha a partir dos dados de recuperação mantidos residentes, então tem permissão para usar até um quarto da RAM da máquina, limitado a 4 GB, e uma máquina que não pode ceder isso silenciosamente usa o método de pouca memória em vez disso - a mesma aritmética e os mesmos tempos das linhas do meio da tabela PAR2, só não o 3× da última. Se você quer o menor conjunto residente possível para um trabalho independente, as ferramentas dedicadas ainda vencem essa coluna.

Prova de transporte · medido na 1.2.2

O motor acompanha linhas reais

• ~8,7 Gbps sustentados por uma frota de cinco provedores em uma linha 10 GbE, incluindo verificação e extração em fluxo - a rodada de 87 GB acima, 24 de agosto de 2026, v1.2.2, 360 conexões: 77,4 GB de rede em 71 s com o payload verificado e extraído à medida que chegava. Não é um número de pico: é o trabalho inteiro nessa taxa.
• A 1 Gbit e abaixo, a linha é o limite e o nzbfast se assenta nele: ~96% de uma linha de 500 Mbit e ~96% de uma linha de 250 Mbit durante a verificação e a extração, a uma fração da memória e do disco de cada rival - a seção sub-gigabit acima.
• O custo de processador do trabalho inteiro no trabalho de 87 GB é 1,7 segundos de CPU por GB com o regulador de conexões ligado - download sobre TLS, verificação, prontidão para reparo e extração incluídos - contra 3,0 a 28 para o campo na mesma rodada; o braço de vazão plena acima gasta 4,3.

Cortes anteriores desta página traziam um conjunto mais amplo de demonstrações de transporte - execuções de saturação multi-linha, ganhos de pipelining por RTT, uma prova de contrapressão, medições de teto de decodificação - corridas em builds que a v1.2.2 desde então superou. Sob a regra desta página elas são retiradas em vez de deixadas envelhecer, e voltam conforme são recortadas de novo no build atual; as três afirmações acima são as que já foram remedidas na v1.2.2.