¿Cuál es el tamaño del búfer para crear un archivo .zip usando Java?

Question

Uso este código para crear un .zip con una lista de archivos:

ZipOutputStream zos = new ZipOutputStream(new FileOutputStream(zipFile));

for (int i=0;i<srcFiles.length;i++){
    String fileName=srcFiles[i].getName();
    ZipEntry zipEntry = new ZipEntry(fileName);
    zos.putNextEntry(zipEntry);
    InputStream fis = new FileInputStream(srcFiles[i]);
    int read;
    for(byte[] buffer=new byte[1024];(read=fis.read(buffer))>0;){
        zos.write(buffer,0,read);
    }
    fis.close();
    zos.closeEntry();
}
zos.close();

No sé cómo funcionan el algoritmo zip y ZipOutputStream, si escribe algo antes de leer y enviar a 'zos' todos los datos, el archivo de resultados puede ser diferente en tamaño de bytes que si elijo otro tamaño del búfer.

en otras palabras, no sé si el algoritmo es como:

LEER DATOS - > DATOS DEL PROCESO - > CREAR .ZIP

o

LEA EL TABLERO DE DATOS - > PROCESO EL CHUNK DE DATOS - > ESCRIBIR EL TABLERO EN .ZIP - > | ^ ------------------------------------------------- -------------------------------------------------- --------------------------

Si este es el caso, ¿qué tamaño de búfer es el mejor?

Actualización:

He probado este código, cambiando el tamaño del búfer de 1024 a 64 y comprimiendo los mismos archivos: con 1024 bytes, el archivo de resultados de 80 KB fue 3 bytes más pequeño que con el búfer de 64 bytes. ¿Cuál es el mejor tamaño de búfer para producir el .zip más pequeño en el menor tiempo?

Answer 1

Respuesta corta: elegiría algo así como 16k.

---

Respuesta larga:

ZIP está utilizando el algoritmo DEFLATE para la compresión ( http://en.wikipedia.org/wiki/DEFLATE ). Deflate es un sabor de Ziv Lempel Welch (buscar en Wikipedia para LZW). DEFLATE utiliza la codificación LZ77 y Huffman.

Esto es una compresión de diccionario, y por lo que sé desde el punto de vista del algoritmo, el tamaño del búfer utilizado cuando se introducen los datos en el desfibrilador casi no debe tener impacto. El mayor impacto para LZ77 es el tamaño del diccionario y la ventana deslizante, que no están controlados por el tamaño del búfer en su ejemplo.

Creo que puedes experimentar con diferentes tamaños de búfer si quieres y trazar una gráfica, pero estoy seguro de que no verás ningún cambio significativo en la relación de compresión (3/80000 = 0.00375%).

El mayor impacto que tiene el tamaño del búfer es en la velocidad debido a la cantidad de código de sobrecarga que se ejecuta cuando realiza las llamadas a FileInputStream.read y zos.write. Desde este punto de vista, debe tener en cuenta lo que gana y lo que gasta.

Al aumentar de 1 byte a 1024 bytes, pierde 1023 bytes (en teoría) y obtiene una reducción de ~ 1024 del tiempo de sobrecarga en los métodos .read y .write. Sin embargo, al aumentar de 1k a 64k, está gastando 63k, lo que reduce la sobrecarga 64 veces.

Así que esto viene con rendimientos decrecientes, así que elegiría en algún lugar en el medio (digamos 16k) y me quedaría con eso.

Answer 2

Depende del hardware que tenga (velocidad del disco y tiempo de búsqueda de archivos). Diría que si no está interesado en exprimir la última gota de rendimiento, elija cualquier tamaño entre 4k y 64k. Como es un objeto de corta duración, se recogerá rápidamente de todos modos.