Zstd: نسبة ضغط أفضل إذا تم تجاهل سياق الضغط بشكل دوري

مرحبا scherepanov ،

هذه النتيجة مدهشة.
باستخدام ZSTD_compressCCtx() ، مع نفس الإدخال ونفس مستوى الضغط ، لا يجب أن يكون الأمر مهمًا (من منظور نسبة الضغط) إذا تمت إعادة استخدام السياق أم لا. التأثير الوحيد لإعادة استخدام السياق هو توفير وقت التخصيص والتهيئة ، هذا كل شيء. إذا كان يؤثر على نسبة الضغط ، فهذا غريب ، وربما يكون خطأ.

أود إعادة إنتاج هذا السيناريو إذا كان ذلك ممكنًا. ما هو الإصدار الذي تستخدمه؟

هل من الأفضل تجاهل سياق الضغط بين ضغط أجزاء كبيرة من البيانات؟

لن تحتاج أبدًا إلى تجاهل السياق.
السبب الوحيد "الجيد" هو تبسيط الكود.
ولكن من منظور الأداء ، يجب أن يكون مفيدًا فقط ، وليس جانبًا سلبيًا.

ما هو الحجم الأمثل لمخزن الإدخال المؤقت الموصى به

هذا هو الموقف للغاية. لا توجد عتبة "عالمية".
بشكل عام ، إذا تجاوز حجم النافذة 8x ، فإن زيادة حجم المجموعة تكون أقل قيمة وأقل.
حجم النافذة ، مع ذلك ، هو قيمة ديناميكية ، اعتمادًا على مستوى الضغط.
يتراوح من 512 كيلوبايت (المستوى 1) إلى 8 ميجابايت (المستوى 19).

أي طريقة لإخبار zstd "استخدم أكبر قدر من الذاكرة كما تريد ولكن أعطني نسبة ضغط أفضل"

من المفترض أن يكون المستوى 19 من هذا النوع

و / أو السرعة "

المستوى 4 بشكل عام من هذا النوع: إنه يضغط بسرعة كبيرة ، لكنه يستخدم قدرًا كبيرًا من الذاكرة. هذا هو أقرب ما يمكنني التفكير فيه.

هل هو فعلاً ضغط متدفق مع سياق جيد فقط لحالات الاستخدام المقيدة بالذاكرة؟ إذا كان لدي الكثير من الذاكرة ، فأنا أفضل حالًا مع ضغط المخازن المؤقتة الكبيرة (> 1 ميجابايت) بشكل مستقل؟

يعد ضغط / فك ضغط الأجزاء المستقلة في مسار واحد ( ZSTD_compressCCtx() و ZSTD_decompressDCtx() ) أمرًا أبسط ، ومن المحتمل أن يكون فعالًا بقدر الإمكان. إذا كنت تستطيع القيام بذلك ، فمن الأفضل. يضيف وضع البث الكثير من التعقيد علاوة على ذلك. غالبًا ما يكون التعقيد داخليًا وخفيًا ، ولكن الفكرة الرئيسية هي أنه لا يمكن أن يكون أفضل / أسرع من الضغط المباشر أو فك الضغط بمرور واحد.

شكرا على الجواب الواضح جدا.
لقد تتبعت نسبة ضغط مختلفة إلى ترتيب مختلف لبياناتي. نعم ، إعادة استخدام السياق مقابل الإهمال لا يحدث فرقًا ، تمامًا كما قلت. آسف ، يجب أن أكون أكثر حرصًا وأتحقق أكثر قبل تقديم الأسئلة.
تعليقاتك واضحة جدا وموضحة جدا. أعتقد أنه يلزم حقًا إضافته إلى المستندات. جزء خاص حول الاختلاف في البث مقابل عدم البث - كنت أعتقد دائمًا أن البث أكثر كفاءة ، حيث يمكنك إنشاء قاموس أفضل (على الرغم من عدم وضوح كيفية تعديل القاموس عندما تتغير البيانات في ملف). من المهم جدًا فهم أن البث يشبه إلى حد كبير الضغط "المستند إلى الكتلة". على الجانب الآخر ، قد يكون البث أكثر فاعلية ، حيث تتعامل تلقائيًا مع حجم الجزء. أنا أستخدم حجم مقطع 1 ميغا بايت مع مستوى ضغط افتراضي 3 ، ويبدو أنه غير كافٍ للحصول على ضغط أفضل. من وجهة النظر هذه ، يمكن أن يكون البث أكثر فاعلية على نسبة الضغط ، حيث ستحدد حجم المقطع بشكل أمثل. (هل هذا صحيح؟؟؟)

الدفق يشبه إلى حد كبير الضغط "المستند إلى الكتلة"

إنه ليس بالضبط "نفس الشيء".

إذا قمت بتقطيع بيانات الإدخال إلى أجزاء ، وقمت بتمريرها بشكل مستقل إلى ZSTD_compressCCtx() ، فسينتهي بك الأمر بقطع متعددة مضغوطة مستقلة. كل جزء مضغوط عبارة عن إطار _ مستقل. يمكن فك ضغطها بأي ترتيب ، لأن كل إطار مستقل.

إذا قمت بإرسال نفس البيانات إلى دفق واحد ، مع ZSTD_compressStream() ، بدون تقسيم ، ينتهي بك الأمر بإطار واحد. داخليا ، يتم قطع الإطار إلى كتل ، نعم ، لكن هذا لا يهم ، لأن الكتل ليست مستقلة. لفك تشفير أي جزء من الإطار ، من الضروري فك تشفير كل شيء من البداية.

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