Quelle est la taille de la mémoire tampon pour créer une archive .zip en utilisant Java?

Question

J'utilise ce code pour créer un fichier .zip avec une liste de fichiers:

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

Je ne sais pas comment fonctionnent l'algorithme zip et le ZipOutputStream. S'il écrit quelque chose avant de lire et d'envoyer à "zos" toutes les données, le fichier de résultat peut être d'une taille en octets différente de celui que j'en ai choisi. taille de la mémoire tampon.

En d'autres termes, je ne sais pas si l'algorithme est comme:

LIRE LES DONNEES - > TRAITER LES DONNEES - > CREER .ZIP

ou

LIRE LE GROUPE DE DONNÉES - > TRAITER LE GROUPE DE DONNÉES - > Écrire le bloc de caractères dans le .ZIP - > | ^ ----------------------------------------------------- -------------------------------------------------- --------------------------

Si tel est le cas, quelle est la taille de la mémoire tampon la mieux adaptée?

Mise à jour:

J'ai testé ce code, en modifiant la taille du tampon de 1024 à 64 et en compressant les mêmes fichiers: avec 1024 octets, le fichier de résultat de 80 Ko était 3 octets plus petit qu'avec un tampon de 64 octets. Quelle est la meilleure taille de tampon pour produire le plus petit fichier .zip en un temps record?

Answer 1

réponse courte: je choisirais quelque chose comme 16k.

Réponse longue:

ZIP utilise l'algorithme DEFLATE pour la compression ( http://fr.wikipedia.org/wiki/DEFLATE ). Deflate est une saveur de Ziv Lempel Welch (recherche sur Wikipédia pour LZW). DEFLATE utilise les codes LZ77 et Huffman.

Il s’agit d’une compression de dictionnaire et, pour autant que je sache du point de vue de l’algorithme, la taille de la mémoire tampon utilisée lors de l’alimentation des données dans le déflater ne devrait avoir pratiquement aucun impact. L’impact le plus important pour LZ77 est la taille du dictionnaire et la fenêtre glissante, qui ne sont pas contrôlés par la taille de la mémoire tampon dans votre exemple.

Je pense que vous pouvez essayer différentes tailles de mémoire tampon si vous le souhaitez et tracer un graphique, mais je suis certain que vous ne verrez aucun changement significatif du taux de compression (3/80000 = 0,00375%).

La taille de la mémoire tampon a un impact majeur sur la vitesse en raison de la quantité de code supplémentaire qui est exécutée lorsque vous passez des appels à FileInputStream.read et à zos.write. De ce point de vue, vous devez prendre en compte ce que vous gagnez et ce que vous dépensez.

Lorsque vous passez de 1 octet à 1024 octets, vous perdez 1023 octets (en théorie) et vous obtenez une réduction de ~ 1024 du temps système dans les méthodes .read et .write. Toutefois, lorsque vous passez de 1 000 à 64 000 $, vous dépensez 63 000 $, ce qui réduit les frais généraux de 64 fois.

Cela vient donc avec des rendements décroissants, donc je choisirais quelque part au milieu (disons 16k) et je m'en tiendrai à cela.

Answer 2

Dépend du matériel dont vous disposez (vitesse du disque et durée de la recherche de fichier). Je dirais que si vous n'êtes pas intéressé par la dernière goutte de performance, choisissez une taille comprise entre 4k et 64k. Comme il s’agit d’un objet de courte durée, il sera quand même rapidement collecté.