2012-04-05 17 views
5

क्या हैशटेबल्स पेड़ों की तुलना में हमेशा तेज हैं? हालांकि हैशटेबल्स में ओ (1) खोज जटिलता है लेकिन मान लीजिए कि बुरी तरह से डिजाइन किए गए हैश फ़ंक्शन के कारण टकराव बहुत सारे होते हैं और यदि हम जंजीर संरचना (संतुलित पेड़ कहें) का उपयोग करके टकराव को संभालते हैं तो खोज के लिए सबसे खराब केस चलने का समय ओ होगा (लॉग n)। तो क्या मैं बड़े या छोटे डेटा सेट के लिए निष्कर्ष निकाल सकता हूं, यहां तक ​​कि सबसे खराब केस परिदृश्य हैश टेबल हमेशा पेड़ों की तुलना में तेज़ होगा? इसके अलावा यदि मेरे पास पर्याप्त स्मृति है और मैं नहीं चाहता कि रेंज की खोज मैं हमेशा हैश टेबल के लिए जा सकता हूं?हैश टेबल वी/एस पेड़

+0

मैं कोई विशेषज्ञ नहीं हूं, लेकिन मैं कहूंगा कि यह स्थितित्मक है। बहुत सारे हैंशिंग फ़ंक्शन महंगी हैं, और कुछ पहुंच पैटर्न के लिए एक पेड़ अच्छा है। –

+0

"हमेशा" इतना बड़ा सर्वव्यापी शब्द है। कोई भी मौका आप इस प्रश्न को कुछ और विशिष्ट विशिष्टताओं के लिए कम करने के लिए संपादित कर सकते हैं, जैसे विशिष्ट परिदृश्य (केवल)? अन्यथा यह लगभग निश्चित रूप से रचनात्मक के रूप में बंद हो जाएगा। –

+1

यहां बहुत से लोगों ने उल्लेख किया है कि सबसे खराब मामला ओ (एन) होगा। यदि यह एक लिंक्ड सूची के बजाय संतुलित वृक्ष संरचना का उपयोग करके टकरावों को संभाला जाता है तो यह ओ (एन) कैसे हो सकता है। एवीएल जैसे संतुलित पेड़ में खोजने का सबसे बुरा मामला ओ (लॉग एन) –

उत्तर

9

क्या हैशटेबल्स पेड़ों की तुलना में हमेशा तेज हैं?

नहीं, हमेशा नहीं। यह कई चीजों पर निर्भर करता है, जैसे संग्रह का आकार, हैश फ़ंक्शन, और कुछ हैश तालिका कार्यान्वयन के लिए - डिलीट ऑप्स की संख्या भी।

हैश-टेबल O(1) प्रति ऑप औसत पर है - लेकिन यह हमेशा ऐसा नहीं होता है। में में वे O(n) हो सकते हैं।

कुछ कारणों मैं इस समय के बारे में सोच सकते हैं पेड़ों को पसंद करते हैं:

  1. आदेश महत्वपूर्ण है। [हैश-टेबल ऑर्डर बनाए नहीं रख रहे हैं, बीएसटी को परिभाषा द्वारा क्रमबद्ध किया गया है]
  2. Latency एक मुद्दा है - और आप O(n) से ग्रस्त नहीं हो सकते हैं। [यह रीयल-टाइम सिस्टम के लिए महत्वपूर्ण हो सकता है]
  3. थर डेटा आपके हैश फ़ंक्शन से संबंधित "समान" हो सकता है, और कई तत्व उसी स्थान पर आते हैं [टक्कर] असंभव नहीं है। [इसे कभी-कभी एक अलग हैश फ़ंक्शन का उपयोग करके हल किया जा सकता है]
  4. अपेक्षाकृत छोटे संग्रह के लिए - कई बार हैशटेबल के O(1) के बीच छिपी स्थिरता पेड़ की तुलना में बहुत अधिक है - और छोटे पेड़ों के लिए पेड़ का उपयोग करना तेज हो सकता है।

हालांकि - यदि डेटा बहुत बड़ा है, तो विलंबता कोई मुद्दा नहीं है और टक्कर असुरक्षित हैं - हैश-टेबल एक पेड़ का उपयोग करके असम्बद्ध रूप से बेहतर होते हैं। टकराव की

+0

अक्सर यह मामला है कि सावधानी से पैक किए गए पेड़ कैश कोहेरेंसी (मुख्य स्मृति या डिस्क से हो) के कारण हैश टेबल निष्पादित कर सकते हैं। इससे कोई फर्क नहीं पड़ता कि इस मामले में आपके पास कितना डेटा है - हैश टेबल आपके शब्दकोश का उपयोग कैसे कर रहे हैं इस पर निर्भर करता है कि आप शब्दकोश संरचना का उपयोग कैसे कर रहे हैं। – Kaganar

+0

क्या हैश टेबल? ओपन एड्रेसिंग हैश टेबल्स या "बाल्टी" हैश टेबल्स? वृद्धिशील आकार के साथ या बिना? या रैखिक हैशिंग आधारित? वहाँ * हैश टेबल के इतने सारे * कार्यान्वयन! उनमें से कुछ के लिए आपका जवाब गलत है, इसलिए कृपया सटीक रहें। –

+0

@MatthieuM .: ये "हैकेट" के रूप में एक सरल सरणी के साथ खुले पते या चेनिंग का उपयोग करते हुए भी बहुत सारी हैश तालिकाओं के लिए पारंपरिक दोष हैं। ऑर्डरिंग कम है क्योंकि हैशिंग गारंटी नहीं देता है कि ऑर्डर जारी रहेगा। लेटेंसी सबसे खराब स्थिति के कारण एक मुद्दा है (यदि आप कुछ बाधाओं के कारण किसी भी 'ओ (एन)' ओप का सामना नहीं कर सकते हैं - यह एक मुद्दा है), इसी तरह हैश वैल्यू वास्तव में एक ड्रॉ बैक नहीं है क्योंकि इसे आसानी से हल किया जा सकता है अलग हैश फ़ंक्शन, और आकार समस्या आमतौर पर हैश फ़ंक्शन ओवरहेड के कारण होती है यदि मुझे सही याद है। आपको विशेष रूप से क्या समस्या है? – amit

0

हैशटेबल का उपयोग करें, और इसे उचित आयाम के साथ init। उदाहरण के लिए यदि आप केवल आधे स्थान का उपयोग करते हैं तो टकराव बहुत कम होते हैं।

0

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

1

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

संबंधित मुद्दे