Каков размер буфера для создания архива .zip с использованием Java?

Question

Я использую этот код для создания .zip со списком файлов:

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

Я не знаю, как работает алгоритм почтового индекса и ZipOutputStream, если он пишет что-то прежде, чем я прочитал и отправить на «Зос 'все данные, файл результатов может быть разным по размеру байтов, чем если бы я выбрал другой размер буфера.

другими словами, я не знаю, если алгоритм, как:

READ DATA -> ПРОЦЕСС DATA -> CREATE .ZIP

или

READ Кусок DATA-- > PROCESS CHUNK OF DATA -> WRITE CHUNK IN .ZIP -> | ^ ------------------------------------------------ -------------------------------------------------- ---------------------------

Если это так, какой размер буфера является лучшим?

Update:

Я испытал этот код, изменяя размер буфера от 1024 до 64, и сжать те же файлы: с 1024 байт результат файла 80 КБ было 3 байта меньше, чем с буфером 64 байта. Каков наилучший размер буфера для создания самого маленького .zip в самое жирное время?

Answer 1

Короткий ответ: я бы выбрал что-то вроде 16k.

---

Длинный ответ:

ZIP использует алгоритм DEFLATE для сжатия (http://en.wikipedia.org/wiki/DEFLATE). Deflate - это аромат Ziv Lempel Welch (поисковая википедия для LZW). DEFLATE использует кодирование LZ77 и Хаффмана.

Это сжатие словаря, и насколько я знаю с точки зрения алгоритма, размер буфера, используемый при подаче данных в дефлатер, не должен иметь никакого эффекта. Наибольшее влияние на LZ77 - размер словаря и скользящее окно, которые не контролируются размером буфера в вашем примере.

Я думаю, что вы можете поэкспериментировать с разными размерами буфера, если хотите и построить график, но я уверен, что вы не увидите существенных изменений в степени сжатия (3/80000 = 0,00375%).

Наибольшее влияние на размер буфера оказывает скорость из-за количества служебного кода, который выполняется при выполнении вызовов FileInputStream.read и zos.write. С этой точки зрения вы должны учитывать, что вы получаете и что вы тратите.

При увеличении от 1 байт до 1024 байт вы теряете 1023 байта (теоретически), и вы получаете уменьшение накладных расходов в методах .read и .write. Однако при увеличении с 1k до 64k вы тратите 63k, что уменьшает накладные расходы 64 раза.

Так что это происходит с уменьшающейся отдачей, поэтому я бы выбрал где-то посередине (скажем, 16k) и придерживался этого.

Answer 2

Зависит от оборудования, которое у вас есть (скорость диска и время поиска файла). Я бы сказал, если вы не заинтересованы в сжатии последней капли производительности, выберите любой размер между 4k и 64k. Так как это недолговечный объект, он будет собран в любом случае.