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

Question

que utiliza 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 el algoritmo de cremallera y el ZipOutputStream funciona, si se 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 de búfer.

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

leer datos -> datos de proceso -> Crear .ZIP

o

LEER trozo de Data-- > PROCESO CHUNK OF DATA -> ESCRIBIR CHUNK IN .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 tampón procedente 1,024 a 64, y comprimir los mismos archivos: con 1024 bytes del archivo de resultados 80 KB fue de 3 bytes más pequeña que con tampón de 64 bytes. ¿Cuál es el mejor tamaño de buffer para producir el .zip más pequeño en el tiempo de prueba?

Answer 1

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

---

Respuesta larga:

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

Esta es una compresión de diccionario, y hasta donde yo sé, desde el punto de vista del algoritmo, el tamaño del búfer utilizado al alimentar los datos en el deflater no debería tener casi ningún 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 un gráfico, 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 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, se pierden 1023 bytes (en teoría) y se obtiene una reducción ~ 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, por lo tanto, yo elegiría un punto intermedio (digamos 16k) y me apegaré a eso.

Answer 2

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