Explications · un
L'essentiel de ce qui rend ce client rapide n'est pas un chemin réseau plus rapide. C'est que les données ne se déplacent qu'une fois. Voici ce que cela veut dire en pratique, en quoi c'est autre chose que le décompactage direct, quelles formes d'archives y survivent, et ce que vaut réellement, sur une vraie machine, la suppression du cycle écriture-puis-relecture.
Le point de départ
Un post, ce sont des milliers de petits articles encodés qui forment ensemble un jeu de volumes d'archive, lesquels contiennent à leur tour le fichier que vous voulez vraiment. Passer de l'un à l'autre a traditionnellement représenté quatre tâches distinctes, chacune s'achevant avant que la suivante ne commence.
Chaque étape est correcte, et le résultat est juste. Mais le contenu a été écrit deux fois, lu au moins deux fois, et au pic le disque a dû contenir deux copies complètes d'une tâche dont vous ne vouliez qu'une seule copie. Le chronomètre que vous vivez, ce sont les quatre étapes à la suite, et c'est pourquoi un client peut annoncer un téléchargement rapide tout en vous faisant attendre.
Le changement
Une passe unique signifie que les octets vont du réseau à leur destination finale sans jamais devenir un fichier d'archive sur votre disque. Il n'y a pas d'étape deux ni trois, parce que le travail des deux se fait pendant que l'étape une tourne encore.
En pratique, chaque article est décodé en mémoire dès son arrivée et remis d'un coup à deux choses à la fois. Le vérificateur le contrôle immédiatement face aux données de parité, si bien que la justesse est établie au moment où les données atterrissent plutôt qu'en les relisant plus tard. L'extracteur traite les octets entrants comme une position dans l'archive, détermine à quelle partie de quel fichier de contenu ils appartiennent, et les écrit là.
Les volumes d'archive ne sont jamais assemblés. Ils existent comme une structure que l'extracteur comprend pendant que le téléchargement est en vol, et la seule chose qui atteint votre disque est le fichier que vous vouliez. Quand le dernier article arrive, il ne reste pour ainsi dire rien à faire, et c'est pourquoi nos temps de fin sont proches du temps de téléchargement lui-même plutôt que d'un téléchargement suivi d'une traîne.
La conséquence mesurable : pour la même tâche nous écrivons environ deux fois moins, relisons bien moins, et avons besoin à peu près de la taille du contenu en espace libre plutôt que du double. Sur une sortie de 190 GB, cela fait environ 157 GB d'espace libre contre environ 313 GB, et à peu près un tiers du trafic disque.
Deux choses rendent cela plus difficile qu'il n'y paraît, et ce sont elles qui expliquent que ce soit rare. Les articles n'arrivent pas dans l'ordre, l'extracteur doit donc composer avec des octets qui atterrissent à des positions arbitraires plutôt qu'en flux depuis le début. Et une archive compressée ne peut pas être décompressée à partir du milieu, donc toute partie du travail qui exige réellement l'ordre doit être reconnue et traitée autrement plutôt qu'écartée par hypothèse.
La comparaison qu'on nous demande
Le décompactage direct est une bonne fonctionnalité et les clients qui en disposent s'en portent mieux. Il résout aussi une autre partie du problème, et la différence se voit exactement là où elle compte.
Le décompactage direct commence à extraire avant la fin du téléchargement, de sorte que l'étape trois chevauche l'étape une au lieu de la suivre. Ce qu'il ne fait pas, c'est supprimer l'étape une. Les volumes d'archive sont toujours écrits en entier sur votre disque, parce que le décompacteur est un décompacteur classique qui lit des fichiers classiques ; le décompactage direct se contente de le démarrer plus tôt. Les deux copies existent toujours, les deux écritures ont toujours lieu, et le besoin d'espace libre est inchangé.
| écrire les volumes sur le disque | espace libre nécessaire | nombre d'écritures du contenu | |
|---|---|---|---|
| Télécharger, puis décompacter | oui, puis relecture | ~2× la tâche | 2 |
| Décompactage direct | oui, relu plus tôt | ~2× la tâche | 2 |
| Une passe | jamais écrits | ~1× la tâche | 1 |
La deuxième différence, c'est ce qui arrive quand la forme n'est pas simple. Comme le décompactage direct confie le travail à un décompacteur classique au fur et à mesure que les volumes apparaissent, il lui faut une situation sans complication : des volumes présents dans un ordre exploitable, aucune réparation en attente, rien à déverrouiller d'abord, et une archive dont le contenu n'est pas lui-même une archive. Dès que l'une de ces conditions manque, la chose sensée à faire est de se retirer et de revenir à un décompactage à la fin, et c'est ce qui se passe. Vous obtenez un résultat correct et le calendrier ordinaire.
Parce que notre extracteur est bâti dès le départ autour d'octets hors séquence, ces situations ne sont pas des exceptions pour lui. Voilà la vraie distinction : non pas que nous commencions plus tôt, mais que nous ne dépendions pas de conditions qui souvent ne sont pas réunies.
Ce qui y survit vraiment
Une conception pareille ne vaut la peine que si elle s'applique aux posts que vous rencontrez vraiment, et non à un cas idéal bien propre. La position actuelle : aucun format de conteneur n'est traité uniquement sur disque. RAR, 7z et zip passent tous par le chemin en une passe.
| forme | une passe | remarques |
|---|---|---|
| RAR, stocké (sans compression) | oui | le cas courant pour les sorties multimédia |
| RAR, compressé | oui | y compris une archive compressée comme couche extérieure |
| RAR 1.5, 3, 4 et 5 | oui | les quatre générations du format |
| 7z | oui | y compris les contenus compressés en deflate |
| zip | oui | y compris les contenus bzip2 et LZMA |
| Contenus chiffrés | oui | avec un mot de passe, y compris le zip chiffré |
| En-têtes chiffrés | oui | quand les noms de fichiers sont cachés aussi |
| Chaînes de mots de passe | oui | le mot de passe de chaque couche rangé dans celle du dessus |
| Archives imbriquées | oui | désimbriquées à la volée, jusqu'à une profondeur configurable |
| Endommagé à plusieurs niveaux | oui | réparation à chaque niveau, toujours en une passe |
| Jeux découpés numériquement | oui | découpages de type name.001 |
| Archives auto-extractibles | passe disque | l'archive ne commence pas au début du fichier |
Zip réparti (.z01) | passe disque | et quelques variantes de zip plus rares |
| Tâches reprises | passe disque | une tâche poursuivie après un redémarrage se termine de façon classique |
Les trois refus sont honnêtes et se comportent tous de la même façon : la tâche s'achève correctement, par le chemin classique, et vous obtenez pour ce téléchargement le calendrier ordinaire à deux copies. Rien n'échoue ; cela cesse simplement d'être rapide à la manière décrite dans le reste de cette page. Les archives auto-extractibles sont refusées pour une raison structurelle et non par manque d'efforts : identifier une archive à ses premiers octets ne peut pas fonctionner quand les premiers octets sont un programme.
Les lignes imbriqué et chiffré sont celles qu'il faut prendre au sérieux, car c'est là que la plupart des clients vous rendent la tâche. Sur un corpus généré de dix formes imbriquées, noté par empreinte de contenu pour qu'un client qui renomme le contenu reçoive quand même le crédit, nous en avons terminé 9 sur 10 sans intervention ; le client suivant en a terminé 5, et deux autres en ont terminé 2. Celle que nous ne terminons pas automatiquement est une échelle à dix niveaux, qui se termine proprement à la limite de profondeur par défaut de cinq en laissant la couche la plus profonde sous forme d'archive saine, et se termine entièrement si vous relevez la limite. Ces manches sont sur la page des benchmarks avec la grille complète.
Pourquoi cela vaut la peine
C'est plus rapide, pour une raison peu glorieuse. Écrire 60 GB et les relire n'est pas gratuit, même sur un disque SSD rapide, et sur tout ce qui est plus lent c'est souvent le vrai goulot d'étranglement plutôt que le réseau. Supprimer une écriture et deux lectures retire entièrement ce temps de votre chronomètre. Le gain est le plus grand exactement là où on le remarque le plus : les grosses tâches, et les machines dont le disque n'est pas la partie la plus rapide.
Cela divise l'usure par deux. Les disques SSD ont un nombre fini d'écritures en eux, et un téléchargeur qui écrit chaque contenu deux fois dépense ce budget à double vitesse sans aucun bénéfice pour vous. Sur quelques centaines de téraoctets téléchargés, ce qui est une année ordinaire pour un utilisateur actif, la différence représente une fraction significative de la vie d'un disque.
Cela change ce qui rentre. L'espace libre n'est pas une caractéristique de performance, c'est un oui ou non. Une tâche qui exige deux fois sa propre taille en marge tourne ou ne tourne pas. N'avoir besoin que d'à peu près la taille du contenu signifie que des tâches aboutissent sur des machines et des volumes où l'approche classique s'arrête net, et c'est pourquoi une sortie de 190 GB tient ici dans environ 157 GB d'espace libre plutôt que dans environ 313 GB.
Cela coûte moins de temps processeur. Ne pas faire passer les données deux fois par le disque supprime le travail que cela demande, et vérifier pendant le téléchargement veut dire aucune seconde passe sur le contenu pour le contrôler. Notre coût processeur reste plat à environ 1.7 seconde-processeur par gigaoctet, d'une tâche de 35 GB à une de 190 GB, et c'est la propriété utile : le coût par gigaoctet n'augmente pas quand la tâche grandit.
Cela tourne avec moins de mémoire, et une mémoire bornée. Comme les octets sont consommés à leur arrivée plutôt qu'accumulés, l'espace de travail est un budget que vous fixez et non une fonction de la taille de la tâche. C'est ce qui permet de traiter une sortie de 190 GB sur une machine disposant d'environ 1.1 GB. La distinction qui compte n'est pas le chiffre mais la forme : une mémoire qui croît avec la tâche finira par rencontrer une tâche que votre machine ne peut pas terminer, et elle échoue en swappant ou en se faisant tuer plutôt qu'en vous prévenant.
Pris ensemble, ces points concernent moins le fait de gagner un benchmark que celui de savoir où le logiciel peut tourner tout court. Une conception qui demande la moitié de l'espace libre, la moitié des écritures et une quantité bornée de mémoire fonctionne sur un petit serveur domestique, un portable plus ancien ou un NAS, et c'est bien là que vit une bonne partie de ce type de logiciel.
Chaque chiffre de cette page est mesuré et publié avec la version et la date à côté, sur la page des benchmarks, y compris les manches que nous perdons. Le contrepoids honnête, indiqué là-bas aussi : un extracteur et un réparateur bâtis pour accompagner un téléchargement en cours occupent plus de mémoire résidente qu'un outil autonome lancé une fois en ligne de commande ; donc si votre contrainte est l'empreinte la plus petite possible pour une tâche unique sur un fichier que vous avez déjà, les outils dédiés gagnent cette colonne.