कचरा का ढेर और उपयोगी काम या विचार में न्यूनतम

हाल ही में, जब मैंने एक नई परियोजना पर स्विच किया, तो मैंने एक बदलाव के लिए ग्रहण से आइडिया में बदलने का फैसला किया। मुझे पहले से ही 6 वें संस्करण के विचार के साथ अनुभव था, मुझे यह पसंद आया, लेकिन इसमें बहुत सारी समस्याएं थीं। फिर मैंने लंबे काम के दौरान आवधिक glitches के कारण इसे मना कर दिया। जब मैंने देखा कि 11 वां संस्करण पहले से ही यार्ड में था, तो मुझे खुशी हुई और मैंने फिर से अपनी किस्मत आजमाने का फैसला किया, क्योंकि इंटरफ़ेस पर मेरे लिए यह विचार बहुत अधिक सुखद है ...

लगभग एक महीने पहले, मैंने देखा कि सक्रिय विकास के साथ, जब गुच्छा के लिए आवंटित की गई 768MB मेमोरी 80% पर भरी हुई थी, तो कोई भी क्रिया, जैसे माउस को हिलाना, फ़ोकस स्विच करना, बस माउस व्हील को स्क्रॉल करना या खिड़की से सीधे स्क्रॉल करना बहुत अधिक मेमोरी खपत का कारण बनता है और शेष 20% मेमोरी खाई जाती है कुछ सेकंड के काम में। जिसके बाद, निश्चित रूप से, आप आरामदायक काम के बारे में भूल सकते हैं और कलेक्टर के निरंतर संचालन को देखते हुए आपको पर्यावरण को अधिभार देना होगा। आज यह स्थिति आखिरकार मुझे मिल गई और मैंने यह पता लगाने का फैसला किया - वास्तव में समस्या क्या है?

सहज रूप से, मैं समझ गया कि सबसे अधिक संभावना है कि हर माउस आंदोलन और स्क्रॉलिंग जैसी कोई भी कार्रवाई कुछ घटनाओं को उत्पन्न करती है, जिन्हें तब संसाधित किया जाता है, लेकिन इसलिए मुझे इन घटनाओं की उम्मीद नहीं थी। बीज के लिए - संपादक विंडो में माउस ले जाने और 1000 लाइनों के लिए एक खुले वर्ग के अंदर स्क्रॉल करने पर मेमोरी खपत के 2 स्क्रीनशॉट:

आंदोलन:
स्क्रॉल:

चरम पर कोड संपादन विंडो में सामान्य स्क्रॉलिंग कुछ सेकंड में लगभग 100MB मेमोरी खाती है ... किसी भी माउस आंदोलन से दसियों मेगाबाइट ऑब्जेक्ट्स उत्पन्न होते हैं ... इन सबके बारे में एकमात्र सकारात्मक बात यह है कि ये सभी ऑब्जेक्ट्स तब एकत्र किए जाते हैं।


स्वाभाविक रूप से, यह मेरे लिए दिलचस्प हो गया कि इस तरह के सरल कार्यों के साथ वास्तव में ऐसा विचार क्या उत्पन्न करता है। तो, चलिए प्रयोग को दोहराते हैं:

स्क्रोल प्रति 1.5 मिलियन ऑब्जेक्ट थोड़ा महंगा है, क्या आप नहीं हैं? लेकिन अब कमोबेश यह साफ हो गया कि समस्या कहां है। यह एक निश्चित वर्ग है IntervalTreeImpl और इसका आंतरिक वर्ग NodeCachedOffsets। अब हमारे पास तलाशने के लिए 2 तरीके हैं: 1) IntervalTreeImpl स्रोतों को डाउनलोड करें और देखें कि NodeCachedOffsets कहाँ और कैसे बनाए गए हैं और उनमें से कई क्यों हैं (वैसे, खुले स्रोत कोड के लिए डेवलपर्स के लिए बहुत धन्यवाद); 2) स्क्रॉल करते समय कॉल स्टैक का विश्लेषण करें।

सबसे पहले, मैं पहले रास्ते पर गया, और फिर जो हो रहा था, उसका अंदाजा लगाते हुए, मैंने कॉल स्टैक का विश्लेषण किया कि आखिर यह सुनिश्चित करने के लिए कि निष्कर्ष सही थे ... इसलिए, कौन परवाह करता है - आप यहां स्रोत पा सकते हैं। उस कोड को देखकर स्वयं यह पता लगाने की कोशिश करें कि समस्या कहाँ है।

कोड का विश्लेषण करने के बाद, यह कम या ज्यादा स्पष्ट हो जाता है कि कॉल स्टैक से क्या उम्मीद की जाए, वास्तव में इसका सबसे दिलचस्प हिस्सा है:

और


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

सामान्य तौर पर, मैं यहाँ समस्या को खूबसूरती से हल करना चाहता था और उसका समाधान प्रदर्शित करना चाहता था, लेकिन ... जब मैंने समस्या को ठीक करने के लिए नवीनतम स्रोतों को डाउनलोड किया तो मेरा आश्चर्य क्या था (git: //git.jetbrains.org/idea/community.it), मैंने कहा कि यह त्रुटि पहले से ही तय हो गई है, और 5 महीने पहले भी ... इस समस्या को यहां देखा जा सकता है । यह अजीब है कि विचार के नवीनतम संस्करण में (11.1.2) यह फिक्स अभी भी नहीं है। मैं इसे जल्द से जल्द प्राप्त करना चाहूंगा ... फिर भी, यह काफी सुखद है कि लोग उत्पाद का ध्यान रखें।