Java Language
जावा प्रदर्शन ट्यूनिंग

सामान्य पहूंच

जावा कार्यक्रमों के प्रदर्शन में सुधार के लिए इंटरनेट युक्तियों से भरा हुआ है। शायद नंबर एक टिप जागरूकता है। इसका मत:

• संभावित प्रदर्शन समस्याओं और अड़चनों को पहचानें।
• विश्लेषण और परीक्षण उपकरणों का उपयोग करें।
• अच्छी प्रथाओं और बुरे व्यवहारों को जानें।

पहला बिंदु डिज़ाइन चरण के दौरान किया जाना चाहिए यदि किसी नई प्रणाली या मॉड्यूल के बारे में बोल रहा हो। अगर विरासत कोड के बारे में बात की जाए, तो विश्लेषण और परीक्षण उपकरण तस्वीर में आते हैं। आपके JVM प्रदर्शन का विश्लेषण करने के लिए सबसे बुनियादी उपकरण JVisualVM है, जो JDK में शामिल है।

तीसरा बिंदु ज्यादातर अनुभव और व्यापक शोध के बारे में है, और निश्चित रूप से कच्चे सुझाव जो इस पेज पर दिखाई देंगे और अन्य, इस तरह।

स्ट्रिंग्स की मात्रा कम करना

जावा में, कई स्ट्रिंग इंस्टेंसेस बनाना बहुत आसान है, जिनकी आवश्यकता नहीं है। उस और अन्य कारणों से आपके कार्यक्रम में बहुत सारी स्ट्रिंग्स हो सकती हैं जो जीसी सफाई में व्यस्त हैं।

कुछ ऐसे तरीके जिनसे आप स्ट्रिंग इंस्टेंसेस बना सकते हैं:

myString += "foo";

या बदतर, एक पाश या पुनरावृत्ति में:

for (int i = 0; i < N; i++) {
    myString += "foo" + i;
}

समस्या यह है कि प्रत्येक + एक नया स्ट्रिंग बनाता है (आमतौर पर, चूंकि नए कंपाइलर कुछ मामलों का अनुकूलन करते हैं)। StringBuilder या StringBuffer का उपयोग करके एक संभावित अनुकूलन बनाया जा सकता है:

StringBuffer sb = new StringBuffer(myString);
for (int i = 0; i < N; i++) {
    sb.append("foo").append(i);
}
myString = sb.toString();

यदि आप अक्सर लंबे स्ट्रिंग्स का निर्माण करते हैं (उदाहरण के लिए SQL), स्ट्रिंग बिल्डिंग API का उपयोग करें।

अन्य बातों पर विचार:

• का उपयोग कम करें replace , substring आदि
• String.toArray() बचें, विशेष रूप से अक्सर एक्सेस कोड में।
• लॉग प्रिंट जिन्हें फ़िल्टर किया जाना है (उदाहरण के लिए लॉग स्तर के कारण) उत्पन्न नहीं किया जाना चाहिए (लॉग स्तर अग्रिम में जांच की जानी चाहिए)।
• यदि आवश्यक हो तो इस तरह से पुस्तकालयों का उपयोग करें।
• यदि स्ट्रिंग को गैर-साझा तरीके से (थ्रेड के पार) में उपयोग किया जाए तो स्ट्रिंगबर्ल बेहतर है।

जावा प्रदर्शन ट्यूनिंग के लिए एक साक्ष्य-आधारित दृष्टिकोण

डोनाल्ड नथ को अक्सर यह कहते हुए उद्धृत किया जाता है:

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

स्रोत

उस ऋषि की सलाह को ध्यान में रखते हुए, यहाँ कार्यक्रम के अनुकूलन के लिए अनुशंसित प्रक्रिया है:

1. सबसे पहले, सादगी और शुद्धता पर ध्यान देने के साथ अपने प्रोग्राम या लाइब्रेरी को डिज़ाइन और कोड करें। आरंभ करने के लिए, प्रदर्शन पर अधिक प्रयास न करें।

2. इसे एक कार्यशील स्थिति में ले जाएं, और (आदर्श रूप से) कोडबेस के प्रमुख भागों के लिए यूनिट परीक्षण विकसित करें।

3. एक एप्लिकेशन स्तर प्रदर्शन बेंचमार्क विकसित करें। बेंचमार्क को आपके आवेदन के प्रदर्शन के महत्वपूर्ण पहलुओं को कवर करना चाहिए, और ऐसे कार्यों की एक श्रृंखला करनी चाहिए जो विशिष्ट हैं कि आवेदन कैसे उत्पादन में उपयोग किया जाएगा।

4. प्रदर्शन को मापें।

5. अपने मापदंड के खिलाफ मापा प्रदर्शन की तुलना करें कि आवेदन कितनी तेजी से होना चाहिए। ("जितनी जल्दी हो सके" जैसे अवास्तविक, अप्राप्य या अप्राप्य मानदंड से बचें।)

6. यदि आप मानदंडों को पूरा कर चुके हैं, तो STOP। आप नौकरी कर रहे हैं (कोई और प्रयास शायद समय की बर्बादी है।)

7. एप्लिकेशन को प्रोफ़ाइल करें जब वह आपके प्रदर्शन बेंचमार्क को चला रहा हो।

8. प्रोफाइलिंग परिणामों की जांच करें और सबसे बड़ा (अडॉप्टिमाइज्ड) "प्रदर्शन हॉटस्पॉट" चुनें; कोड के ऐसे भाग जहां एप्लिकेशन सबसे अधिक समय खर्च करता प्रतीत होता है।

9. हॉटस्पॉट कोड अनुभाग का विश्लेषण करके यह समझने की कोशिश करें कि यह अड़चन क्यों है, और इसे तेज़ बनाने का तरीका सोचें।

10. लागू करें कि प्रस्तावित कोड परिवर्तन, परीक्षण और डीबग के रूप में।

11. यह देखने के लिए कि क्या कोड परिवर्तन ने प्रदर्शन में सुधार किया है, फिर से बेंचमार्क करें:

    • यदि हाँ, तो चरण 4 पर लौटें।
    • यदि नहीं, तो परिवर्तन को छोड़ दें और चरण 9 पर लौटें। यदि आप कोई प्रगति नहीं कर रहे हैं, तो अपने ध्यान के लिए एक अलग हॉटस्पॉट चुनें।

आखिरकार आप एक बिंदु पर पहुंच जाएंगे, जहां एप्लिकेशन या तो काफी तेज है, या आपने सभी महत्वपूर्ण हॉटस्पॉट पर विचार किया है। इस बिंदु पर आपको इस दृष्टिकोण को रोकने की आवश्यकता है। यदि कोड का एक खंड समग्र समय का 1% (मान) का उपभोग कर रहा है, तो भी 50% सुधार केवल आवेदन को 0.5% तेजी से समग्र बनाने के लिए हो रहा है।

स्पष्ट रूप से, एक बिंदु है जिसके आगे हॉटस्पॉट अनुकूलन प्रयास की बर्बादी है। यदि आप उस बिंदु पर पहुंचते हैं, तो आपको अधिक कट्टरपंथी दृष्टिकोण अपनाने की आवश्यकता है। उदाहरण के लिए:

• अपने कोर एल्गोरिदम की एल्गोरिथम जटिलता को देखें।
• यदि एप्लिकेशन बहुत समय कचरा संग्रह कर रहा है, तो ऑब्जेक्ट निर्माण की दर को कम करने के तरीकों की तलाश करें।
• यदि एप्लिकेशन के प्रमुख भाग सीपीयू गहन और एकल-थ्रेडेड हैं, तो समानता के अवसरों की तलाश करें।
• यदि एप्लिकेशन पहले से ही बहु-थ्रेडेड है, तो संगामिति अड़चनें देखें।

लेकिन जहां भी संभव हो, अपने अनुकूलन प्रयास को निर्देशित करने के लिए वृत्ति के बजाय औजारों और माप पर निर्भर रहें।