Frage

Ich benutze diesen Code eine .zip mit einer Liste von Dateien zu erstellen:

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

Ich weiß nicht, wie die Zip-Algorithmus und der ZipOutputStream funktioniert, wenn es etwas schreibt, bevor ich zu ‚ZOS‘ alle Daten lesen und senden, können die Ergebnisdatei in der Größe von Bytes anders sein, als wenn ich einen anderen wählen Puffergröße.

Mit anderen Worten ich weiß nicht, ob der Algorithmus wie:

Daten -> PROZESSDATEN -> CREATE .ZIP

oder

READ Datenblock -> PROCESS Datenpaket -> WRITE CHUNK IN .ZIP -> | ^ ------------------------------------------------- -------------------------------------------------- --------------------------

Wenn dies der Fall ist, welche Puffergröße ist die beste?

Update:

Ich habe diesen Code getestet, die Puffergröße 1024-64 zu ändern, und die gleichen Dateien zippen: mit 1024 Byte der 80 KB Ergebnisdatei 3 Byte kleiner war als mit 64 Byte Puffern. Welches ist die beste Puffergröße der kleinste .zip in der fatest Zeit zu produzieren?

War es hilfreich?

Lösung

Kurze Antwort. Ich würde so etwas wie 16k wählen


Lange Antwort:

ZIP wird mit dem DEFLATE Algorithmus für die Komprimierung ( http://en.wikipedia.org/wiki/DEFLATE ). Deflate ist ein Geschmack von Ziv Lempel Welcher (Suche wikipedia für LZW). DEFLATE verwendet LZ77 und Huffman-Kodierung.

Dies ist ein Wörterbuch Kompression, und soweit ich aus dem Algorithmus Standpunkt kenne die Puffergröße verwendet, wenn die Daten in die deflater Fütterung sollte so gut wie keine Auswirkungen hat. Die größten Auswirkungen für LZ77 sind Wörterbuch Größe und Schiebefenster, die durch die Puffergröße in Ihrem Beispiel gesteuert werden nicht.

Ich glaube, Sie mit verschiedenen Puffergrößen experimentieren können, wenn Sie ein Diagramm wollen und plotten, aber ich bin sicher, dass Sie keine wesentlichen Änderungen des Verdichtungsverhältnisses nicht sehen (3/80000 = 0,00375%).

Die größte Auswirkung der Puffergröße ist auf die Geschwindigkeit aufgrund der Menge an Overhead-Code hat, der ausgeführt wird, wenn Sie die Anrufe FileInputStream.read und zos.write machen. Von diesem Standpunkt aus sollten Sie berücksichtigen, was Sie gewinnen und was Sie ausgeben können.

Wenn von 1 Byte bis 1024 Byte zu erhöhen, verlieren Sie 1023 Bytes (in der Theorie) und Sie eine ~ 1024 Reduzierung der Overhead-Zeit in der .lesen und .WRITE Methoden gewinnen. Jedoch, wenn sie von 1k bis 64k zu erhöhen, Sie verbringen 63k, die den Kopf 64 mal reduziert werden.

So kommt diese mit abnehmenden, so würde ich irgendwo in der Mitte wählen (sie 16k sagen) und mit dem Stick.

Andere Tipps

Abhängig von der Hardware, die Sie (Plattengeschwindigkeit und Datei-Suchzeit) haben. Ich würde sagen, wenn Sie das letzte Quäntchen Leistung nicht daran interessiert sind, quetschen eine Größe zwischen 4k und 64k holen. Da ist es ein Objekt kurzlebig wird es schnell sowieso gesammelt werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top