2012-03-17 16 views
6

मैं सी #, .NET 4.0, 64-बिट का उपयोग कर रहा हूं। मुझे 500 मिलियन "डेटा पॉइंट्स" मेमोरी में स्टोर करने की ज़रूरत है जो कम्प्यूटेशंस में उपयोग की जाती हैं। मुझे यह तय करने की ज़रूरत है कि इन्हें संरचना या कक्षा वस्तुओं के रूप में बनाना है या नहीं। स्ट्रक्च बहुत तेज लगते हैं।.NET स्टैक मेमोरी सीमा

क्या ढेर के लिए स्मृति सीमा है? यदि हां, तो इसे कैसे समायोजित किया जा सकता है।

स्टैक पर इतना डेटा संग्रहीत करना सिस्टम के समग्र प्रदर्शन को प्रभावित करेगा?

(वैसे, मैं .NET में एकल-ऑब्जेक्ट आकार सीमा से अवगत हूं, इसलिए इसे संबोधित किया जा रहा है - डेटा एकाधिक संग्रहों में संग्रहीत किया जाएगा)।

+1

क्या आप वाकई ढेर के साथ ढेर को भ्रमित नहीं कर रहे हैं? –

+1

किस आधार पर आप दावा करते हैं/मानते हैं कि कक्षाएं वर्गों की तुलना में "इतनी तेज़ी से" हैं? –

+0

मुझे लगता है कि ओपी स्टैक आवंटन और संरचना, जो गलत है, के बीच कठिन संबंध बनाता है। ये पूरी तरह से अलग विषय हैं, जो * संबंधित हो सकते हैं। – Tigran

उत्तर

6

आप गलत सवाल पूछ रहे हैं। यदि ढेर आकार मायने रखता है, तो आप कुछ गलत कर रहे हैं।

यदि आप कई डेटापॉइंट्स का उपयोग करते हैं, तो आप उन्हें एक संग्रह में डाल देंगे, जैसे सरणी। तीर को हमेशा ढेर पर आवंटित किया जाता है। Structs की एक सरणी व्यक्तिगत structs को एम्बेड करता है और एक सतत स्मृति ब्लॉक बनाता है। (यदि आपके पास 2 जीबी से अधिक है, तो आपको कई एरे की आवश्यकता है)।

जबकि संदर्भ प्रकारों के साथ, सरणी में केवल संदर्भ होंगे, और वस्तुओं को ढेर पर व्यक्तिगत रूप से आवंटित किया जाएगा। एक ढेर आवंटन में लगभग 16 बाइट ओवरहेड होते हैं, सरणी में संदर्भ दूसरे के लिए खाते 8. 8.
आपको संकेतों के कारण भी खराब कैश इलाके मिल जाएगा, और जीसी को उन सभी संदर्भों को क्रॉल करने के लिए और अधिक काम करना है।

मेरा निष्कर्ष यह है कि यदि आपके पास बहुत छोटे डेटापॉइंट हैं, तो उन्हें एक संरचना बनाएं, और उन्हें एक सरणी में रखें।

1

आप अपने डेटा पॉइंट के लिए कक्षाओं का उपयोग कर सकते हैं। इस मामले में, ढेर पर स्मृति आवंटित की जाएगी।

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

+0

मेरे अनुभव में डेटाबेस के ऊपरी हिस्से के बिना बड़ी मात्रा में डेटा तक तेजी से पहुंच की आवश्यकता होती है। और यदि आप उन्हें स्मृति में लोड करते हैं तो आपको संदर्भ प्रकारों का उपयोग करने के लिए केवल 12 जीबी ओवरहेड मिलता है। अच्छा नहीं है। – CodesInChaos

+0

@CodeInChaos: सहमत हैं। वास्तव में सुझाव के अनुसार, उन्हें स्मृति में सभी लोड न करें, लेकिन डेटा रखने के लिए कुछ 'डीबी' परत का उपयोग करें। – Tigran

+1

अक्सर आप प्रदर्शन कारणों से उन्हें स्मृति में रखना चाहते हैं। उदाहरण के लिए मैं अक्सर भौतिकी सिमुलेशन के साथ काम करता हूं जहां बड़े सरणी में दर्जनों जीबी डेटा होते हैं। – CodesInChaos

4

आप अपने डेटा को सरणी में संग्रहीत करने जा रहे हैं और सरणी हमेशा ढेर पर संग्रहीत होती हैं। तो इससे कोई फर्क नहीं पड़ता कि आप उन सरणी को पकड़ने के लिए structs या कक्षाओं का उपयोग करते हैं या नहीं। आप यह सुनिश्चित करना चाहते हैं कि आपके डेटा बिंदु मूल्य प्रकार (यानी structs) हैं ताकि डेटा बिंदुओं के सरणी स्मृति के संगत ब्लॉक में कुशलतापूर्वक आवंटित किए जा सकें।

ढेर और ढेर आवंटित स्मृति के बीच प्रदर्शन अंतर छोटी वस्तुओं के साथ देखा जा सकता है जो आवंटित और समय की थोड़ी देर में आवंटित किए जाते हैं। आपके द्वारा वर्णित आकार के लंबे समय तक रहने वाली वस्तुओं के लिए, मैं उम्मीद करता हूं कि स्टैक और ढेर आवंटित स्मृति के बीच प्रदर्शन में कोई अंतर नहीं होगा।

+0

बात यह है कि अगर ढेर पर संरचना आवंटित की जाती है तो यह तेजी से आवंटन के अपने "लाभ" (प्रश्न बिंदु के दृष्टिकोण से) खो देता है। – Tigran

+0

@Tigran 500 मिलियन डेटा पॉइंट्स पर ऑपरेशन करने के बाद उन मतभेदों को अतुलनीय होने जा रहे हैं। –

+2

@Tigran नहीं अगर यह एक सरणी का हिस्सा है। स्ट्रक्चर सरणी में निरंतर मेमोरी ब्लॉक में समाप्त हो जाएंगे, जबकि कक्षाओं को एक नया उदाहरण मिलेगा (संबंधित 16 बाइट ओवरहेड के साथ) और अतिरिक्त संकेत। – CodesInChaos

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