लंबे समय तक चलने वाले एप्लिकेशन लिखते समय - उस तरह के प्रोग्राम जो दिन का अधिकांश समय टास्कबार में कम से कम खर्च करेंगे या सिस्टम ट्रे, यह महत्वपूर्ण हो सकता है कि कार्यक्रम को स्मृति उपयोग के साथ 'दूर भाग' न दें।
दो सबसे दाहिने कॉलम सीपीयू (समय) के उपयोग और मेमोरी उपयोग का संकेत देते हैं। यदि कोई प्रक्रिया इन दोनों में से किसी पर भी गंभीर प्रभाव डालती है, तो आपका सिस्टम धीमा हो जाएगा।
सीपीयू के उपयोग पर अक्सर प्रभाव डालने वाला एक ऐसा प्रोग्राम है जो लूपिंग है (किसी प्रोग्रामर से पूछें जो किसी फाइल प्रोसेसिंग लूप में "रीड नेक्स्ट" स्टेटमेंट डालना भूल गया है)। उन प्रकार की समस्याओं को आमतौर पर काफी आसानी से ठीक किया जाता है।
दूसरी ओर, मेमोरी का उपयोग हमेशा स्पष्ट नहीं होता है और इसे सही से अधिक प्रबंधित करने की आवश्यकता होती है। उदाहरण के लिए मान लें कि एक कैप्चर टाइप प्रोग्राम चल रहा है।
इस कार्यक्रम का उपयोग पूरे दिन सही तरीके से किया जाता है, संभवतः एक हेल्प डेस्क पर टेलिफोनिक कैप्चर के लिए, या किसी अन्य कारण से। बस इसे हर बीस मिनट में बंद करने और फिर इसे फिर से शुरू करने का कोई मतलब नहीं है। इसका उपयोग पूरे दिन के दौरान किया जाएगा, हालांकि कई बार अंतराल पर।
यदि यह कार्यक्रम कुछ भारी आंतरिक प्रसंस्करण पर निर्भर करता है या इसके रूपों पर बहुत सारी कलाकृति है, तो जल्दी या बाद में स्मृति उपयोग अन्य अधिक लगातार प्रक्रियाओं के लिए कम मेमोरी छोड़कर, पेजिंग गतिविधि को आगे बढ़ाने और अंततः कंप्यूटर को धीमा करने के लिए, बढ़ने जा रहा है।
मान लीजिए कि आप एक प्रोग्राम को मुख्य रूप और दो अतिरिक्त (मोडल) रूपों के साथ डिज़ाइन करने जा रहे हैं। आमतौर पर, आपके डेल्फी संस्करण के आधार पर, डेल्फी रूपों को सम्मिलित करने जा रहा है परियोजना इकाई (डीपीआर फ़ाइल) और एप्लिकेशन स्टार्टअप पर सभी फॉर्म बनाने के लिए एक लाइन शामिल होगी (एप्लीकेशन) CreateForm (...)
प्रोजेक्ट यूनिट में शामिल लाइनें डेल्फी डिज़ाइन द्वारा हैं और उन लोगों के लिए बहुत अच्छी हैं जो डेल्फी से परिचित नहीं हैं या बस इसका उपयोग करना शुरू कर रहे हैं। यह सुविधाजनक और सहायक है। इसका अर्थ यह भी है कि कार्यक्रम शुरू होने पर और न कि जरूरत पड़ने पर सभी फॉर्म बनाए जाने वाले हैं।
इस बात पर निर्भर करता है कि आपकी परियोजना किस बारे में है और आपके द्वारा एक फॉर्म को लागू की गई कार्यक्षमता बहुत सारी मेमोरी का उपयोग कर सकती है, इसलिए रूपों (या सामान्य रूप में: वस्तुओं) को केवल तब बनाया जाना चाहिए जब वे जरूरतमंद और नष्ट (मुक्त) हो जाते हैं जैसे ही वे अब नहीं हैं ज़रूरी।
दोनों, "DialogForm" और "OccasionalForm" को "ऑटो-क्रिएट फॉर्म" की सूची से हटाने और "उपलब्ध फ़ॉर्म" सूची में ले जाने की आवश्यकता है।
कृपया ध्यान दें कि यहां उल्लिखित रणनीति इस धारणा पर आधारित है कि प्रश्न में कार्यक्रम एक वास्तविक समय "कैप्चर" प्रकार का कार्यक्रम है। हालांकि, यह बैच प्रकार प्रक्रियाओं के लिए आसानी से अनुकूलित किया जा सकता है।
डेल्फी इसे कम करने की कोशिश की है और इसकी अपनी स्मृति प्रबंधन वास्तुकला है जो बहुत छोटे ब्लॉकों का उपयोग करता है लेकिन यह है विंडोज वातावरण में लगभग बेकार क्योंकि स्मृति आवंटन अंततः ऑपरेटिंग सिस्टम के साथ टिकी हुई है।
एक बार विंडोज ने एक प्रक्रिया को मेमोरी का एक ब्लॉक आवंटित किया है, और यह प्रक्रिया 99.9% मेमोरी को मुक्त कर देती है, विंडोज अभी भी पूरे ब्लॉक का उपयोग करने का अनुभव करेगा, भले ही ब्लॉक का केवल एक बाइट वास्तव में हो रहा हो उपयोग किया गया। अच्छी खबर यह है कि विंडोज इस समस्या को साफ करने के लिए एक तंत्र प्रदान करता है। शेल हमें एक एपीआई नाम प्रदान करता है SetProcessWorkingSetSize. यहाँ हस्ताक्षर हैं:
परिभाषा के अनुसार, SetProcessWorkingSetSize फ़ंक्शन निर्दिष्ट प्रक्रिया के लिए न्यूनतम और अधिकतम कामकाजी सेट आकार निर्धारित करता है।
इस एपीआई का उद्देश्य प्रक्रिया के मेमोरी उपयोग स्थान के लिए न्यूनतम और अधिकतम मेमोरी सीमाओं की निम्न स्तर की सेटिंग की अनुमति देना है। हालाँकि, इसमें थोड़ा क्वर्की बनाया गया है जो सबसे भाग्यशाली है।
यदि न्यूनतम और अधिकतम दोनों मूल्य $ FFFFFFFF पर सेट किए जाते हैं, तो API अस्थायी रूप से सेट आकार को 0 पर ट्रिम कर देगा, इसे मेमोरी से बाहर स्वैप कर, और तुरंत ही रैम में वापस उछलता है, इसमें उसे आवंटित न्यूनतम न्यूनतम मात्रा की मेमोरी होगी (यह सब नैनोसेकंड के एक जोड़े के भीतर होता है, इसलिए उपयोगकर्ता को यह होना चाहिए अतीन्द्रिय)।
इस एपीआई के लिए एक कॉल केवल दिए गए अंतराल पर किया जाएगा - लगातार नहीं, इसलिए प्रदर्शन पर बिल्कुल भी कोई प्रभाव नहीं होना चाहिए।
अब, समय-समय पर "अब" के खिलाफ अंतिम टिक गणना की जांच करें और यदि दोनों के बीच का अंतर सुरक्षित निष्क्रिय अवधि के रूप में समझी गई अवधि से अधिक है, तो मेमोरी ट्रिम करें।
अब तय करें कि आप किस अवधि में कार्यक्रम को निष्क्रिय कर देंगे। हमने मेरे मामले में दो मिनट का फैसला किया, लेकिन आप परिस्थितियों के आधार पर किसी भी अवधि को चुन सकते हैं।
लंबे प्रसंस्करण समय या बैच प्रक्रियाओं के लिए इस पद्धति को अनुकूलित करना काफी सरल है। आम तौर पर आपके पास एक अच्छा विचार होगा जहां एक लंबी प्रक्रिया शुरू होगी (जैसे लाखों डेटाबेस रिकॉर्ड के माध्यम से एक लूप पढ़ने की शुरुआत) और जहां यह (डेटाबेस रीड लूप का अंत) समाप्त होगा।
बस प्रक्रिया की शुरुआत में अपने टाइमर को अक्षम करें, और प्रक्रिया के अंत में इसे फिर से सक्षम करें।