सिल्वरलाइट धीमा क्यों हो रहा है?

सवाल "सिल्वरलाइट धीमा क्यों होता है?" आप अक्सर सुन सकते हैं, खासकर यदि आप सिल्वरलाइट तकनीक का उपयोग करके समाधान विकसित कर रहे हैं। अक्सर आप अपने आवेदन में सिल्वरलाइट तकनीक का उपयोग करने के लिए एक निविदा नहीं जीत सकते, या एक ग्राहक को मना कर सकते हैं, सिर्फ इसलिए कि उसने पहले ही यह सोचकर लोकप्रियता हासिल कर ली है कि सभी सिल्वरलाइट अनुप्रयोग धीमे हैं। आइए इस मुद्दे पर चर्चा करने का प्रयास करें।

SQL.RU के साथ उदाहरण

हाल ही में, मैंने WPF थ्रेड , सिल्वरलाइट फ़ोरम http://sql.ru में पोस्ट देखना शुरू किया, वहाँ मैंने MVVM फ्रेमवर्क (मेरी स्थिति ज्ञात है ) का उपयोग करने की सिफारिश दी, और इस प्रश्न में भाग गया:

लेकिन मुझे यह न बताएं कि जब मैं इसे नहीं छूता हूं तो प्रोसेसर इस साइट के लिंक में से एक द्वारा क्या करता है ? क्या धारणाएं हैं?

पाचन: सामान्य तौर पर, sql.ru फ़ोरम के इंप्रेशन ऐसे होते हैं कि किसी भी धागे में सिल्वरलाइट अच्छी है या नहीं, इस बारे में केवल एक बाढ़ की शुरुआत होती है।



तो, बहुत आवेदन के बारे में http://surfity.com/#/Images । दरअसल, यदि आप खोज में कुछ टाइप करते हैं, और फिर खोज बटन पर क्लिक करते हैं, तो खोज के बाद आप स्वयं ही निम्न चित्र पा सकते हैं:







डाउनटाइम के दौरान, एप्लिकेशन प्रोसेसर को लगभग पूर्ण रूप से उपयोग करना जारी रखता है। बैकग्राउंड में कुछ करता है। यह स्पष्ट है कि आवेदन की ऐसी दृढ़ता से सब कुछ धीमा हो जाता है। मैं इस बात का जवाब नहीं दे सकता कि वास्तव में इस तरह की समस्या क्यों है। लेकिन एक बार मैंने एक समान बग हल किया, मेरे द्वारा नहीं बनाया गया, लेकिन जिसे कोई भी डेवलपर स्वीकार कर सकता है।

हमारी टीम का उदाहरण

विचार सरल था। एक चार्ट था जो सिंकफ़्यूज़न नियंत्रण (मेरे पसंदीदा नियंत्रण , इस बार हमारा था) का उपयोग करके तैयार किया गया था। कार्य एक लाइन प्रदर्शित करने के लिए था (जैसे लक्ष्य रेखा: एक लाल रेखा जो इंगित करती है कि जहां "अच्छा" नियमित कॉलम चार्ट में "बुरा" में बदल जाता है)। कुछ इस तरह से देखा गया:







चार्ट नियंत्रण, इस मामले में, समन्वय अक्षों के लिए आवश्यक उन्नयन की गणना करता है, और, मूल्य संग्रह में मौजूद अधिकतम और न्यूनतम मानों के आधार पर, अक्षों पर अधिकतम और न्यूनतम सेट करता है। चित्र में यह लगभग 70 से 80 है। तब, उदाहरण के लिए, डेवलपर को पता है कि लक्ष्य रेखा 78 है - उसे यह देखना होगा कि क्या ऑर्डिनेट अक्ष पर ऐसा कोई मान है, और यदि ऐसा है, तो एक रेखा खींचें। जाहिर है, उसे चार्ट नियंत्रण से किसी प्रकार के ईवेंट की आवश्यकता है, जैसे कि "चार्ट बनाया गया है और तैयार है", ताकि वह यह निर्धारित कर सके कि लाइन कहां खींचनी है, लेकिन ऐसा कोई इवेंट नहीं है। एक विकल्प लेआउटअपडेट किए गए ईवेंट की सदस्यता लेना है, जिसे चार्ट तैयार होने के बाद कॉल किया जाएगा:

public partial class MainPage : UserControl { public MainPage() { InitializeComponent(); Chart.LayoutUpdated += new EventHandler(Chart_LayoutUpdated); } void Chart_LayoutUpdated(object sender, EventArgs e) { // Draw line... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और Chart_LayoutUpdated पद्धति में, चार्ट नियंत्रण के लिए एक पंक्ति जोड़ें। ऐसा लगता है कि सब कुछ सरल है। लागू होने के बाद, हम जाँचते हैं कि सब कुछ ठीक है। हम TFS को सोर्स कोड भेजते हैं। समस्या देखें? मुझे लगता है कि कई लोग इसे तुरंत नोटिस नहीं कर सकते।



बहुत परीक्षण के बाद, आवेदन लेने वाले व्यक्ति का कहना है: "सब कुछ ठीक है, लेकिन आवेदन पूरी तरह से धीमा हो जाता है, क्या आप किसी तरह इसे अपनी सिल्वरलाइट तेज कर सकते हैं?"। यह स्पष्ट है कि आपके पास एक मानक उत्तर तैयार है, जैसे "यह एक व्यावसायिक अनुप्रयोग है, नोटबुक नहीं है, यह स्पष्ट है कि यह धीमा हो जाता है क्योंकि यह काम करता है।" लेकिन यह मेरे मामले में नहीं है, मुझे विकास के समय से प्रदर्शन की समस्याओं को हल करना पसंद है। C ++ में, जब उन्होंने एक एप्लिकेशन बनाया, जिसने ड्रॉ आकर्षित किया, और जब 40 सेकंड के बजाय डिबग के तहत बनाया गया एक एप्लिकेशन 10 में ड्रॉइंग बनाना शुरू किया (एक सेकंड में रिलीज में), तो मैंने एक वास्तविक चर्चा का अनुभव किया। इसलिए, मैंने उत्तर दिया कि मैं यह देखने की कोशिश करूंगा कि क्या किया जा सकता है। सबसे पहले, मैंने एप्लिकेशन खोला और उसके साथ लंबे समय तक और कड़ी मेहनत करना शुरू कर दिया, मुझे कोई गंभीर मेमोरी लीक नहीं दिखी, यह 150 से 200 एमबी तक खा रहा था, और यह उस ढांचे के भीतर बना रहा। लेकिन उन्होंने देखा कि अगर कुछ भी नहीं किया गया था, तो स्क्रीन पर अभी भी एक प्रोसेसर पर 30-40% प्रोसेसर खाना जारी है, हालांकि अन्य 5% पर। यह अच्छा है कि मेरे पास सिल्वरलाइट स्पाई एप्लिकेशन था, जिसके साथ मैंने अपने आवेदन का विश्लेषण करना शुरू किया और इवेंट मॉनिटर में देखा कि इस बहुत ही समस्याग्रस्त स्क्रीन पर, इवेंट लेआउटअप्ड को चक्रीय और लगातार कहा जाता है। फिर मैं इस कोड और इस समस्या से परिचित हुआ। बेशक, ग्राफ खींचे जाने के बाद और लेआउटअप इवेंट को निकाल दिया जाता है, हम नियंत्रण में एक और तत्व जोड़ते हैं, और निश्चित रूप से उसी इवेंट लेआउटअपडेट को फिर से कहा जाता है, और इसी तरह एक सर्कल में।



मुझे बताओ, आप कितनी बार अपने अनुप्रयोगों का परीक्षण करते हैं ताकि यह लंबे समय तक काम कर सके? आप कितनी बार एक साधारण टास्क मैनेजर भी खोलते हैं यह देखने के लिए कि आपका आवेदन कैसे व्यवहार करता है?

निष्कर्ष

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



तो, सिल्वरलाइट एप्लिकेशन क्यों धीमा हो रहे हैं? क्योंकि यह तकनीक वेब डेवलपर्स को शुरुआती से गुरु तक वेब एप्लिकेशन लिखने की अनुमति देती है: एक अनुकूल विकास वातावरण, एक बहुत ही सरल विकास भाषा, संदर्भ सामग्री की एक बड़ी राशि। क्या नौसिखिया डेवलपर लेना संभव है और उसे एचटीएमएल + जावास्क्रिप्ट या फ्लैश में एक वेब एप्लिकेशन बनाने के लिए कहें ताकि यह काम करे, क्या यह भी दिलचस्प / आकर्षक है? मैं व्यावसायिक अनुप्रयोगों, विश्वकोश साइटों और छोटे खिलौने और बैनर के बारे में बात नहीं कर रहा हूँ। मैं इस जवाब को 90% उत्तर "नहीं" में आत्मविश्वास के साथ देता हूं।



इसलिए, भविष्य में, यदि आप सिल्वरलाइट पर समाधान विकसित करने पर ध्यान केंद्रित करते हैं, तो विचार करें:

• आपको आवेदन के व्यवहार का अध्ययन करने में समय बिताने की आवश्यकता है;
• टीम में आपके पास एक होना चाहिए (संख्या परियोजना पर निर्भर करती है, निश्चित रूप से) विशेषज्ञ जो प्रदर्शन के साथ गंभीर समस्याओं को हल कर सकते हैं, और लोगों को समझा सकते हैं कि ये समस्याएं क्यों होती हैं;
• यह एक प्रबंधित वातावरण है, और इसलिए, काम के चरम पर, यदि आप स्मृति के साथ बहुत सावधान नहीं हैं, तो आप केवल काम के लिए स्मृति के विशाल सरणियों को अव्यवस्थित कर सकते हैं, जो तुरंत जारी नहीं किया जाएगा;

और कम अवरोधित अनुप्रयोग बनाते हैं



PS यह सुनिश्चित करने से अधिक कि प्रश्न दिखाई देंगे: "सिल्वरलाइट पर एक सामान्य अनुप्रयोग दिखाएं"। मैं तुरंत जवाब दूंगा कि मैं ऐसे लोगों को नहीं जानता। हमारा आवेदन, सिद्धांत रूप में, अच्छा व्यवहार करता है, ग्राहक संतुष्ट हैं, हम जैसे ही पैदा होते हैं, हम प्रदर्शन के साथ समस्याओं को हल करते हैं। मैं इसे नहीं दिखा सकता, क्योंकि यह एक इंट्रानेट एप्लिकेशन है।