हमारे पास .NET 4.0 में लिखा गया एक सी # डब्ल्यूपीएफ एप्लीकेशन है, जो कुछ अपेक्षाकृत सरल डेटा बाध्यकारी और ग्रिड कार्यक्षमता है।डब्ल्यूपीएफ सी # अनुप्रयोग प्रदर्शन
स्टाइल कुछ होवर रंगों सहित कुछ 'ट्वीक्स' का आविष्कार करता है।
20 मशीनों पर तैनाती से बाहर 3 मशीनों पर, हम यूआई के साथ कुछ बहुत ही अजीब प्रदर्शन समस्याओं का सामना कर रहे हैं।
प्रभावी रूप से, रीबूट के बाद एप्लिकेशन अच्छा प्रदर्शन करता है, लेकिन एक निश्चित (अन-निर्धारित) समय के बाद, यूआई अविश्वसनीय रूप से सुस्त हो जाता है। उदाहरण के लिए, माउस को एक बटन पर घुमाएं, और होवर रंग स्टाइल लागू/प्रस्तुत होने से पहले कुछ सेकंड तक देरी होगी।
मशीनों में लगभग समान विनिर्देश हैं। ग्राफिक्स ड्राइवर अपडेट किए गए हैं, और स्टारंडर्ड सेटअप दो एनवीडिया क्वाड्रो 2 9 0 कार्ड हैं। Additoinally, हमने एक 'परीक्षण' एप्लिकेशन बनाया है जिसमें केवल कुछ परीक्षण UI घटक (फ्लुएंट रिबन समेत) और कोई कोड पीछे नहीं है। समस्या अभी भी होती है।
मैंने विंडोज परफॉर्मेंस सूट को रनटाइम डब्ल्यूपीएफ में 'गहरी गोताखोरी' चलाने के लिए चलाया है, और बहुत अजीब बात यह है कि यदि यूआई 'गंदा क्षेत्र समर्थन अक्षम करें' विकल्प चुना जाता है तो यूआई सामान्य प्रतिक्रिया देता है। मेरी समझ यह है कि, अगर कुछ भी हो, तो इसे और प्रदर्शन कम करना चाहिए !!!
मैं यहां कोशिश करने के लिए किसी और चीज की हानि में हूं। एक डॉटट्रेस प्रदर्शन विश्लेषण से पता चलता है कि अधिकांश आवेदन समय प्रस्तुति Framework.dll में बिताया जाता है।
[संपादित करें] सभी मशीनें विंडोज एक्सपी एसपी 3 हैं।
[संपादित करें] यह संभव है कि यह सभी मशीनों पर होता है और एप्लिकेशन को आमतौर पर समस्या को पेश करने के लिए पर्याप्त समय तक चलाने की अनुमति नहीं दी जाती है। हम अभी इसका परीक्षण कर रहे हैं।
[संपादित करें] मुझे यह भी इंगित करना चाहिए कि हम हॉटफिक्स विस्तृत here के साथ प्रयोग कर रहे हैं। यह इस समय के लिए एक मशीन पर स्थापित किया गया है, और मैं तदनुसार अद्यतन करूँगा।
[संपादित करें - 24 घंटे बाद] तो दो मशीनें अब रात भर एक ही कोड चला रही हैं। मेरी मशीन पर (जिसने कभी समस्या का प्रदर्शन नहीं किया है), एप्लिकेशन में प्रारंभिक लॉग बहुत आलसी था, लेकिन एक मिनट से भी कम समय में सामान्य हो गया। (मैंने इसे मशीन पर सीधे एचडीडी से चीजों को खींचने के लिए रखा)। दूसरी मशीन (जो आमतौर पर समस्या का प्रदर्शन करती है) पर, कुछ सेकंड के बाद आवेदक में सुधार हुआ, लेकिन अब भी मेरी तुलना में सुस्त है।
[संपादित करें - 48 घंटे बाद] परीक्षण मशीन पर, 48 घंटे के लिए परीक्षण आवेदन अब पूरी तरह उत्तरदायी (लॉक) है। एक ही मशीन पर, हल्के 'खोल' WPF अनुप्रयोग (जिसमें टैब नियंत्रण, कुछ बटन और कुछ पैनल और ग्रिड होते हैं) अभी भी चल रहे हैं और पूरी तरह उत्तरदायी हैं। तो इन अधिक जटिल नियंत्रणों में से कुछ इस मुद्दे का कारण बन रहा है ... जो वास्तव में (संभावित रूप से) ट्रिगर्स और प्रतिनिधियों को इंगित करता है जो मूल कारण हो सकते हैं। मैं फिर से एप्लिकेशन/नियंत्रण प्रोफाइल करने के लिए देखता हूँ। इस बीच किसी को भी यह सुनिश्चित करने के बारे में कोई सलाह है कि एप्लिकेशन नियमित अंतराल पर स्वयं के बाद 'सफाई' कर लेता है? क्योंकि हम यहां तीसरे पक्ष के नियंत्रण को देख रहे हैं, इसलिए उन्हें संपादित करने के लिए मेरे विकल्प सीमित हैं!
प्रदान की जा सकने वाली किसी भी युक्ति की सराहना करेंगे!
क्या कोड प्रदान करना संभव है? कुछ अन्य SO'er शायद यह भी कोशिश करना पसंद करेंगे। मुद्दों से पहले कम से कम समय कितना समय लगता है? – Default
यदि आवश्यक हो तो मैं कोड प्रदान कर सकता हूं ... लेकिन इस समय हमारे परीक्षण आवेदन में शाब्दिक रूप से केवल एक फ्लुएंट रिबन (कोडप्लेक्स से डेल करने योग्य), और खाली ग्रिड का उपयोग करना शामिल है। स्पष्ट init कॉल के अलावा पीछे कोई कोड नहीं है। अगर मैं जीवन को आसान बना दूंगा तो मैं निश्चित रूप से यह ज़िप्ड अप प्रदान करूंगा। – Nick
प्रोटोटाइप सिस्टम से ज्यादा उम्मीद न करें। पहले चरण के रूप में मैं प्रतिनिधियों के उपयोग की जांच करता हूं। क्या आप अक्सर उपयोग करते हैं? –