Explicaciones · uno
La mayor parte de lo que hace rápido a este cliente no es una ruta de red más veloz. Es que los datos se mueven una sola vez. Esto es lo que eso significa en la práctica, por qué es algo distinto del desempaquetado directo, qué formas de archivo lo sobreviven, y cuánto vale de verdad, en una máquina real, eliminar el ciclo de escribir y volver a leer.
El punto de partida
Un post son miles de artículos pequeños codificados que juntos forman un conjunto de volúmenes de archivo, los cuales a su vez contienen el fichero que realmente quieres. Ir de lo uno a lo otro han sido tradicionalmente cuatro trabajos separados, cada uno terminando antes de que empiece el siguiente.
Cada etapa es correcta, y el resultado es acertado. Pero el contenido se ha escrito dos veces, se ha leído al menos dos veces, y en el punto más alto el disco tuvo que albergar dos copias completas de un trabajo del que solo querías una copia. El reloj que tú vives son las cuatro etapas seguidas, y por eso un cliente puede informar de una descarga rápida y aun así tenerte esperando.
El cambio
Una sola pasada significa que los bytes van de la red a su destino final sin llegar nunca a ser un archivo en tu disco. No hay etapa dos ni tres, porque el trabajo de ambas ocurre mientras la etapa uno sigue en marcha.
En la práctica, según llega cada artículo se descodifica en memoria y se entrega directamente a dos cosas a la vez. El verificador lo contrasta de inmediato con los datos de paridad, así que la corrección queda establecida mientras los datos aterrizan, y no releyéndolos después. El extractor trata los bytes entrantes como una posición dentro del archivo, calcula a qué parte de qué fichero de contenido pertenecen, y los escribe ahí.
Los volúmenes del archivo no se ensamblan nunca. Existen como una estructura que el extractor entiende mientras la descarga va en vuelo, y lo único que llega a tu disco es el fichero que querías. Cuando llega el último artículo no queda prácticamente nada por hacer, y por eso nuestros tiempos de llegada quedan cerca del propio tiempo de descarga en vez de una descarga más una cola.
La consecuencia medible: para el mismo trabajo escribimos aproximadamente la mitad, releemos mucho menos, y necesitamos más o menos el tamaño del propio contenido en espacio libre en vez del doble. En un lanzamiento de 190 GB eso son unos 157 GB de espacio libre frente a unos 313 GB, y aproximadamente un tercio del tráfico de disco.
Dos cosas lo hacen más difícil de lo que suena, y son la razón de que sea poco común. Los artículos no llegan en orden, así que el extractor tiene que arreglárselas con bytes que aterrizan en posiciones arbitrarias en vez de como un flujo desde el principio. Y un archivo comprimido no se puede descomprimir desde la mitad, así que cualquier parte del trabajo que realmente exija orden hay que reconocerla y tratarla de otra manera en vez de darla por supuesta.
La comparación que nos preguntan
El desempaquetado directo es una buena función y los clientes que la tienen salen ganando. También resuelve otra parte del problema, y la diferencia se ve exactamente donde importa.
El desempaquetado directo empieza a extraer antes de que la descarga haya terminado, de modo que la etapa tres se solapa con la etapa uno en vez de seguirla. Lo que no hace es eliminar la etapa uno. Los volúmenes del archivo se siguen escribiendo enteros en tu disco, porque el desempaquetador es uno convencional que lee ficheros convencionales; el desempaquetado directo solo lo arranca antes. Las dos copias siguen existiendo, las dos escrituras siguen ocurriendo, y la necesidad de espacio libre no cambia.
| escribir los volúmenes en el disco | espacio libre necesario | veces que se escribe el contenido | |
|---|---|---|---|
| Descargar y luego desempaquetar | sí, y luego relectura | ~2× el trabajo | 2 |
| Desempaquetado directo | sí, releído antes | ~2× el trabajo | 2 |
| Una sola pasada | nunca se escriben | ~1× el trabajo | 1 |
La segunda diferencia es qué pasa cuando la forma no es sencilla. Como el desempaquetado directo pasa el trabajo a un desempaquetador convencional según van apareciendo los volúmenes, necesita que la situación sea despejada: los volúmenes presentes en un orden utilizable, ninguna reparación pendiente, nada que haya que desbloquear primero, y un archivo cuyo contenido no sean a su vez archivos. Cuando falla alguna de esas cosas, lo sensato es retirarse y recurrir a desempaquetar al final, y eso es lo que pasa. Obtienes un resultado correcto y los tiempos de siempre.
Como nuestro extractor está construido desde el principio en torno a bytes fuera de orden, esas situaciones no son excepciones para él. Esa es la verdadera distinción: no que empecemos antes, sino que no dependemos de condiciones que a menudo no se cumplen.
Qué lo sobrevive de verdad
Un diseño así solo merece la pena si se aplica a los posts que te encuentras de verdad, y no a un caso ideal limpio. La posición actual: ningún formato contenedor se maneja solo en disco. RAR, 7z y zip pasan todos por la ruta de una sola pasada.
| forma | una sola pasada | notas |
|---|---|---|
| RAR, almacenado (sin compresión) | sí | el caso habitual en lanzamientos multimedia |
| RAR, comprimido | sí | incluido un archivo comprimido como capa exterior |
| RAR 1.5, 3, 4 y 5 | sí | las cuatro generaciones del formato |
| 7z | sí | incluidos los contenidos comprimidos con deflate |
| zip | sí | incluidos los contenidos bzip2 y LZMA |
| Contenidos cifrados | sí | con contraseña, incluido el zip cifrado |
| Cabeceras cifradas | sí | cuando los nombres de fichero también están ocultos |
| Cadenas de contraseñas | sí | la contraseña de cada capa guardada en la de encima |
| Archivos anidados | sí | desanidados al vuelo, hasta una profundidad configurable |
| Dañado en varias capas | sí | reparación en cada nivel, sigue siendo una pasada |
| Conjuntos partidos numéricamente | sí | particiones al estilo name.001 |
| Archivos autoextraíbles | pasada en disco | el archivo no empieza al principio del fichero |
Zip repartido (.z01) | pasada en disco | y algunas variantes de zip más raras |
| Trabajos reanudados | pasada en disco | un trabajo continuado tras un reinicio termina de forma convencional |
Las tres negativas son honestas y se comportan igual: el trabajo se completa correctamente, por la vía convencional, y para esa descarga obtienes los tiempos de siempre con dos copias. Nada falla; simplemente deja de ser rápido de la manera que describe el resto de esta página. Los archivos autoextraíbles se rechazan por una razón estructural y no por falta de empeño: identificar un archivo por sus primeros bytes no puede funcionar cuando los primeros bytes son un programa.
Las filas de anidado y cifrado son las que hay que tomarse en serio, porque ahí es donde la mayoría de los clientes te devuelven el trabajo. Sobre un corpus generado de diez formas anidadas, calificado por hash del contenido para que un cliente que renombre el contenido siga recibiendo el crédito, completamos 9 de 10 sin intervención; el siguiente mejor cliente completó 5, y otros dos completaron 2. La que no completamos automáticamente es una escalera de diez niveles, que acaba limpiamente en el límite de profundidad por omisión de cinco dejando la capa más profunda como un archivo sano, y se completa entera si subes el límite. Esas vueltas están en la página de benchmarks con la rejilla completa.
Por qué merece la pena hacerlo
Es más rápido, por una razón poco vistosa. Escribir 60 GB y volver a leerlos no es gratis ni siquiera en una unidad de estado sólido rápida, y en cualquier cosa más lenta suele ser el auténtico cuello de botella en lugar de la red. Quitar una escritura y dos lecturas quita ese tiempo de tu reloj por completo. La ganancia es mayor justo donde más se nota: trabajos grandes, y máquinas cuyo disco no es su parte más rápida.
Reduce el desgaste a la mitad. Las unidades de estado sólido tienen dentro un número finito de escrituras, y un descargador que escribe cada contenido dos veces gasta ese presupuesto al doble de ritmo sin ningún beneficio para ti. A lo largo de unos cuantos cientos de terabytes descargados, que es un año normal para un usuario activo, la diferencia es una fracción apreciable de la vida de una unidad.
Cambia lo que cabe. El espacio libre no es una característica de rendimiento, es un sí o un no. Un trabajo que necesita el doble de su propio tamaño como margen o se ejecuta o no. Necesitar aproximadamente el tamaño del contenido significa que hay trabajos que se completan en máquinas y volúmenes donde el enfoque convencional simplemente se para, y por eso un lanzamiento de 190 GB cabe aquí en unos 157 GB de espacio libre en vez de en unos 313 GB.
Cuesta menos tiempo de procesador. No mover los datos dos veces por el disco elimina el trabajo de hacerlo, y verificar durante la descarga significa ninguna segunda pasada sobre el contenido para comprobarlo. Nuestro coste de procesador se mantiene plano en unos 1.7 segundos de procesador por gigabyte, desde un trabajo de 35 GB hasta uno de 190 GB, y esa es la propiedad útil: el coste por gigabyte no crece según crece el trabajo.
Se ejecuta con menos memoria, y con memoria acotada. Como los bytes se consumen según llegan en vez de acumularse, el conjunto de trabajo es un presupuesto que fijas tú y no una función del tamaño del trabajo. Eso es lo que permite procesar un lanzamiento de 190 GB en una máquina con aproximadamente 1.1 GB disponibles. La distinción que importa no es el número sino la forma: una memoria que crece con el trabajo acabará encontrándose con un trabajo que tu máquina no puede terminar, y falla intercambiando a disco o siendo matada en vez de avisándote.
En conjunto, esto tiene menos que ver con ganar un benchmark que con dónde puede ejecutarse el software siquiera. Un diseño que necesita la mitad del espacio libre, la mitad de las escrituras y una cantidad acotada de memoria funciona en un servidor doméstico pequeño, un portátil más viejo o un NAS, y ahí es donde vive buena parte de este software.
Cada cifra de esta página está medida y publicada con la compilación y la fecha al lado en la página de benchmarks, incluidas las vueltas que perdemos. El contrapeso honesto, dicho allí también: un extractor y un reparador construidos para acompañar una descarga en curso mantienen más memoria residente que una herramienta independiente lanzada una vez desde la línea de órdenes, así que si tu restricción es la huella más pequeña posible para un trabajo puntual sobre un fichero que ya tienes, las herramientas dedicadas ganan esa columna.