2012-07-26 18 views
6

के आकार से दोगुना है, मैंने निम्नलिखित व्यवहार देखा। मैं निम्नलिखित बहुआयामी सरणी बनाने कहते हैं:आर की आरक्षित स्मृति आवंटित सरणी

spam = array(runif(96*48*60*360), dim = c(96,48,60,360)) 

यह काफी उम्मीद के मुताबिक ज्यादा मेमोरी आर अर्थात् इस के लिए उपयोग करना चाहिए कैसे, है (96 * 48 * 60 * 360) * 4 बाइट्स = 759.4 Mbyte। यह अच्छी तरह से lsos समारोह का उपयोग कर पुष्टि की है (this post देखें):

> lsos() 
     Type  Size PrettySize Rows Columns 
spam array 796262520 759.4 Mb 96  48 
lsos function  776 776 bytes NA  NA 

आर के रूप में एक ऐसी प्रक्रिया है लेकिन बहुत अधिक स्मृति, मोटे तौर पर दो बार आकार का उपयोग करता:

$ top | grep rsession 
82:17628 hiemstra 20 0 1614m **1.5g** 8996 S 0.3 40.4 0:04.85 rsession 

आर ऐसा क्यों करता है? मुझे लगता है कि आर के लिए इसे अधिक तेज़ी से सुलभ बनाने के लिए अतिरिक्त आरक्षित मेमोरी आवंटित की गई है? कोई विचार?

उत्तर

6

क्योंकि कचरा कलेक्टर अभी तक नहीं चला है।
तो बहुत सारे कचरे हैं, शायद बड़े सरणी के निर्माण के दौरान उत्पन्न होते हैं, जिन्हें साफ़ किया जाना चाहिए।

आप gc() कार्यप्रणाली को कॉल करके एक कचरा संग्रहण के लिए मजबूर हैं, तो आप यह है कि इस्तेमाल किया स्मृति अपने सरणी के आकार के बहुत पास हो जाएगा देखेंगे:

> memory.size() 
[1] 775.96 
अंत सरणी 759.4 मेबाइट्स का उपयोग करता है में
+0

तो, लेकिन सृजन के दौरान यह और अधिक उपयोग करता है? यह दुर्भाग्यपूर्ण हो सकता है कि सरणी स्मृति में फिट बैठती है, लेकिन सृजन के दौरान स्मृति उपयोग में स्पाइक उपलब्ध स्मृति की तुलना में अधिक उपयोग करता है। –

+1

ठीक है, मुझे नहीं पता कि हुड के नीचे क्या होता है, लेकिन आपके कोड के साथ आप केवल सरणी आवंटित नहीं कर रहे हैं; वास्तव में, सबसे पहले आप यादृच्छिक संख्याओं का वेक्टर उत्पन्न करते हैं, फिर आप उन मानों की प्रतिलिपि बनाकर एक सरणी आवंटित करते हैं। तो, मुझे लगता है कि अधिकांश ओवरहेड (अर्थात् कचरा) उस फेंकने वाले वेक्टर के कारण है ... – digEmAll

+0

हालांकि, मुझे लगता है कि कचरा कलेक्टर स्वचालित रूप से ट्रिगर होता है जब आप स्मृति से बाहर होते हैं तो मुझे नहीं लगता कि यह प्रदर्शन होगा जहां तक ​​सरणी स्मृति में फिट बैठती है ... – digEmAll

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