Qual é o tamanho do buffer para criar um arquivo .zip usando Java?

Question

Eu uso este código para criar um arquivo .zip com uma lista de arquivos:

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();

Eu não sei como o algoritmo zip eo ZipOutputStream funciona, se ele escreve algo antes de eu ler e enviar para 'zos' todos os dados, o arquivo de resultado pode ser diferente em tamanho de bytes do que se eu escolher outra tamanho do buffer.

Em outras palavras eu não sei se o algoritmo é semelhante:

ler dados -> PROCESSO DE DADOS -> CRIAR .ZIP

ou

LEIA PEDAÇO DE DADOS -> PROCESSO PEDAÇO DE DADOS -> Escrever PEDAÇO DE .ZIP -> | ^ ------------------------------------------------- -------------------------------------------------- --------------------------

Se este for o caso, o buffer de tamanho é o melhor?

Update:

Eu testei este código, alterar o tamanho do buffer de 1024-64, e fechando os mesmos arquivos: com 1024 bytes do arquivo de resultado 80 KB foi de 3 bytes menor do que com buffer de 64 bytes. Qual é o melhor tamanho do buffer para produzir a menor .zip no tempo fatest?

Answer 1

Resposta curta:. Eu escolheria algo como 16k

---

Resposta longa:

ZIP está usando o algoritmo deflacionar para compressão ( http://en.wikipedia.org/wiki/DEFLATE ). Deflate é um sabor de Ziv Lempel Welch (search wikipedia para LZW). DEFLATE usa LZ77 e Huffman codificação.

Esta é uma compressão de dicionário, e, tanto quanto eu sei do ponto de vista algoritmo o tamanho do buffer utilizado quando se alimentam os dados no deflater deve ter quase nenhum impacto. O maior impacto para LZ77 são tamanho do dicionário e janela deslizante, que não são controlados pelo tamanho do buffer no seu exemplo.

Eu acho que você pode experimentar com diferentes tamanhos de buffer se você quiser e traçar um gráfico, mas eu tenho certeza que você não vai ver quaisquer alterações significativas na taxa de compressão (3/80000 = 0,00375%).

O maior impacto do tamanho do buffer tem é sobre a velocidade devido à quantidade de código sobrecarga que é executada quando você faz as chamadas para FileInputStream.read e zos.write. A partir deste ponto de vista que você deve levar em conta o que você ganha eo que você gasta.

Ao aumentar a partir de 1 byte a 1024 bytes, você perde 1023 bytes (em teoria) e você ganha a ~ 1.024 redução do tempo de sobrecarga na .read e métodos .write. No entanto, quando o aumento de 1k a 64k, você está gastando 63k que reduzindo a sobrecarga 64 vezes.

Então, isso vem com retornos decrescentes, assim eu escolheria algum lugar no meio (digamos 16k) e ficar com isso.

Answer 2

Depende do hardware você tem (velocidade do disco e tempo de busca de arquivos). Eu diria que se você não está interessado em espremer a última gota de desempenho escolher qualquer tamanho entre 4k e 64k. Uma vez que é um objeto de curta duração que será recolhido rapidamente de qualquer maneira.