ما هو حجم المخزن المؤقت إلى إنشاء أرشيف البريدي باستخدام جافا؟

Question

وأنا استخدم هذا الرمز إلى إنشاء البريدي مع قائمة من الملفات:

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، إذا كان يكتب شيئا قبل أن أقرأ وإرسالها إلى "المنطقة العازلة" كافة البيانات والملفات النتيجة يمكن أن تكون مختلفة في حجم بايت مما لو اخترت آخر حجم المخزن المؤقت.

وبعبارة أخرى أنا لا أعرف إذا كان الخوارزمية مثل:

وقراءة البيانات -> معالجة البيانات -> CREATE مضغوط

أو

وقراءة قطعة من البيانات -> PROCESS قطعة من البيانات -> الكتابة قطعة IN مضغوط -> | ^ ------------------------------------------------- -------------------------------------------------- --------------------------

وإذا كان هذا هو الحال، ما حجم المخزن المؤقت هو أفضل؟

تحديث:

ولقد اختبرت هذا الرمز، وتغيير حجم المخزن المؤقت 1024-64، وفتح سوستة الملفات نفسها: مع 1024 بايت كان الملف نتيجة 80 KB 3 بايت أصغر من العازلة مع 64 بايت. الذي هو أفضل حجم المخزن المؤقت لإنتاج أصغر الرمز البريدي في fatest وقت؟

Answer 1

والجواب باختصار: أود أن اختيار شيء من هذا القبيل في 16K

---

والإجابة الطويلة:

وZIP يستخدم خوارزمية انكماش للضغط ( http://en.wikipedia.org/wiki/DEFLATE ). يدحض هو نكهة زيف Lempel ولش (البحث ويكيبيديا لLZW). انكماش يستخدم LZ77 وهوفمان الترميز.

وهذا هو ضغط القاموس، وبقدر ما أعرف من وجهة نظر خوارزمية حجم المخزن المؤقت تستخدم عند تغذية البيانات في المفرغ ينبغي أن يكون أي تأثير تقريبا. أكبر الأثر لLZ77 هي حجم القاموس والانزلاق النافذة، والتي لا تسيطر عليها حجم المخزن المؤقت في المثال الخاص بك.

وأعتقد يمكنك تجربة مع أحجام مختلفة عازلة إذا كنت تريد ورسم بياني، ولكن أنا واثق من أنك لن ترى أي تغييرات كبيرة في نسبة الضغط (3/80000 = 0.00375٪).

وأكبر تأثير حجم المخزن المؤقت له على سرعة نظرا لكمية من التعليمات البرمجية في سماء المنطقة التي يتم تنفيذها عند إجراء المكالمات إلى FileInputStream.read وzos.write. من وجهة النظر هذه يجب أن تأخذ بعين الاعتبار ما تكسب وما تنفقه.

عند زيادة من 1 بايت إلى 1024 بايت، تخسر 1023 بايت (نظريا) ويمكنك الحصول على ~ 1024 تقليص الوقت علوي في. اقرأ وأساليب. اكتب. ولكن عند زيادة من 1K إلى 64K، كنت تنفق 63K الذي خفض النفقات العامة 64 مرات.

وحتى هذا يأتي مع تناقص الغلة، وبالتالي أود أن اختيار مكان ما في الوسط (دعنا نقول 16K) والعصا مع ذلك.

Answer 2

وتعتمد على الأجهزة لديك (سرعة القرص وملف وقت البحث). أود أن أقول إذا كنت لا ترغب في عصر آخر قطرة من الأداء اختيار أي حجم بين 4K و64K. لأنه هو كائن لم يدم طويلا سيتم جمعها بسرعة على أي حال.