Zstd: बेहतर संपीड़न अनुपात यदि संपीड़न संदर्भ समय-समय पर त्याग दिया जाता है

हाय @scherepanov ,

यह परिणाम आश्चर्यजनक है।
समान इनपुट और समान संपीड़न स्तर के साथ ZSTD_compressCCtx() का उपयोग करते हुए, यह संदर्भ (पुन: उपयोग किए जाने वाले परिप्रेक्ष्य) से कोई फर्क नहीं पड़ता है या नहीं। संदर्भ को फिर से उपयोग करने का एकमात्र प्रभाव आवंटन और आरंभीकरण समय को बचाने के लिए है, बस। यदि यह संपीड़न अनुपात को प्रभावित करता है, तो यह अजीब है, और यह शायद गलत है।

यदि संभव हो तो मैं इस परिदृश्य को पुन: पेश करना चाहूंगा। आपके द्वारा कौन सा संस्करण उपयोग किया जा रहा है ?

क्या डेटा के बड़े हिस्से को संपीड़ित करने के बीच संपीड़न संदर्भ को छोड़ना बेहतर अभ्यास है?

आपको कभी भी संदर्भ त्यागने की आवश्यकता नहीं होनी चाहिए।
कोड को सरल बनाने का एकमात्र "अच्छा" कारण है।
लेकिन एक प्रदर्शन के नजरिए से, यह केवल फायदेमंद होना चाहिए, कोई नकारात्मक पहलू नहीं।

अनुशंसित इष्टतम इनपुट बफर आकार क्या है

यह अत्यधिक स्थितिजन्य है। कोई "सार्वभौमिक" सीमा नहीं है।
सामान्यतया, 8x विंडो आकार से परे, बढ़ते हुए चंक का आकार कम और कम मूल्यवान है।
विंडो का आकार, हालांकि, एक गतिशील मूल्य है, जो संपीड़न स्तर पर निर्भर करता है।
यह 512 केबी (स्तर 1) से 8 एमबी (स्तर 19) तक भिन्न होता है।

Zstd को बताने का कोई भी तरीका "जितना चाहें उतना मेमोरी का उपयोग करें लेकिन मुझे बेहतर कम्प्रेशन रेशियो दें"

लेवल 19 को इस तरह का माना जाता है

और / या गति "

स्तर 4 आम तौर पर इस तरह का होता है: यह बहुत तेजी से संपीड़ित करता है, लेकिन स्मृति की एक बाहरी मात्रा का उपयोग करता है। मैं उसके बारे में सबसे ज्यादा सोच सकता हूं।

क्या यह वास्तव में केवल स्मृति-बाधित उपयोग के मामलों के लिए संदर्भ के साथ स्ट्रीमिंग संपीड़न अच्छा है? यदि मेरे पास बहुत मेमोरी है, तो मैं स्वतंत्र रूप से बड़े (> 1 एमबी) बफ़र्स को संपीड़ित करने के साथ बेहतर हूं?

एक ही पास ( ZSTD_compressCCtx() और ZSTD_decompressDCtx() ) में स्वतंत्र विखंडन को संपीड़ित करना केवल सादा सरल है, और जितना संभव हो उतना कुशल हो सकता है। यदि आप इसे कर सकते हैं, तो यह बेहतर है। स्ट्रीमिंग मोड उस के शीर्ष पर बहुत अधिक जटिलता जोड़ता है। जटिलता ज्यादातर आंतरिक और छिपी हुई है, लेकिन मुख्य विचार यह है कि, यह सीधा / पास संपीड़न या विघटन से बेहतर / तेज नहीं हो सकता है।

बहुत स्पष्ट उत्तर के लिए धन्यवाद।
मैंने अपने डेटा के अलग-अलग ऑर्डर करने के लिए विभिन्न संपीड़न अनुपात का पता लगाया। हां, फिर से संदर्भ बनाम त्याग करने से कोई फर्क नहीं पड़ता, जैसा आपने कहा था। क्षमा करें, मुझे प्रश्न दर्ज करने से पहले अधिक सावधान रहना चाहिए और जांच करनी चाहिए।
आपकी टिप्पणियाँ बहुत स्पष्ट और बहुत स्पष्ट हैं। मुझे लगता है कि इसे डॉक्स में जोड़ना होगा। विशेष रूप से स्ट्रीमिंग बनाम गैर-स्ट्रीमिंग के अंतर के बारे में - मुझे हमेशा लगता था कि स्ट्रीमिंग अधिक कुशल है, क्योंकि आप बेहतर शब्दकोश बना सकते हैं (हालांकि यह स्पष्ट नहीं है कि जब आप किसी फ़ाइल में डेटा बदलते हैं तो आप शब्दकोश को कैसे संशोधित करते हैं)। स्पष्ट समझ कि स्ट्रीमिंग "ब्लॉक-आधारित" संपीड़न के समान ही बहुत महत्वपूर्ण है। दूसरी तरफ, स्ट्रीमिंग अधिक कुशल हो सकती है, क्योंकि आप स्वचालित रूप से चंक आकार को संभालते हैं। मैं डिफ़ॉल्ट संपीड़न स्तर 3 के साथ 1 एमबी चंक आकार का उपयोग कर रहा हूं, और बेहतर संपीड़न प्राप्त करने के लिए अपर्याप्त लगता है। इस दृष्टिकोण से, स्ट्रीमिंग संपीड़न अनुपात पर अधिक कुशल हो सकती है, क्योंकि आप चंक आकार को और अधिक बेहतर तरीके से निर्धारित करेंगे। (क्या यह सही है???)

स्ट्रीमिंग "ब्लॉक-आधारित" संपीड़न के रूप में बहुत अधिक है

यह बिल्कुल "वही" नहीं है।

यदि आप इनपुट डेटा को विखंडू में काटते हैं, और उन्हें स्वतंत्र रूप से ZSTD_compressCCtx() , तो आप कई स्वतंत्र संपीड़ित विखंडों के साथ समाप्त होते हैं। प्रत्येक संकुचित हिस्सा एक स्वतंत्र _frame_ है। वे किसी भी क्रम में विघटित हो सकते हैं, क्योंकि प्रत्येक फ्रेम स्वतंत्र है।

यदि आप एक ही स्ट्रीम में ZSTD_compressStream() साथ एक ही डेटा भेजते हैं, बिना chunking के, आप एक _single फ्रेम_ के साथ समाप्त होते हैं। आंतरिक रूप से, फ्रेम को ब्लॉकों में काट दिया जाता है, हां, लेकिन इससे कोई फर्क नहीं पड़ता, क्योंकि ब्लॉक स्वतंत्र नहीं हैं। फ्रेम के किसी भी हिस्से को डीकोड करने के लिए, शुरुआत से ही सब कुछ डिकोड करना आवश्यक है।

सिद्धांत रूप में, एकल फ़्रेम को कई स्वतंत्र फ़्रेमों से बेहतर संपीड़ित करना चाहिए। ऐसा इसलिए है क्योंकि कई स्वतंत्र विखंडू में डेटा काटने से यह प्रत्येक चंक की शुरुआत में कुछ संपीड़न अवसर खो देता है।
हालांकि, फास्ट मोड केवल "संभाव्य" कम्प्रेसर हैं, जो तेजी से चलाने के लिए जल्दबाजी में दांव लगाते हैं। सभी अवसर समान नहीं होते हैं, और कभी-कभी, एक अवसर का चयन करने से बाद में बेहतर अवसर प्राप्त होता है। यह बहुत विशिष्ट डेटा है।
इसलिए, कुछ दुर्लभ मामलों में, ऐसा हो सकता है कि स्वतंत्र विखंडू में डेटा काटने से एकल धारा के साथ प्रतिस्पर्धा समाप्त हो जाए।
लेकिन मैं उस पर दांव नहीं लगाऊंगा। ज्यादातर मामलों में, एकल धारा को जीतना चाहिए, यदि केवल बहुत कम से।