5

मैं कुछ स्टार्टअप टाइम चिंताओं का निवारण करने की कोशिश कर रहा हूं। कुछ प्रोफाइलिंग करने के बाद, मैंने पाया है कि मुख्य अपराधी क्लासप्रोक्सी जेनरेटर है। जेनरेट कोड। यह पहली बार 400-600ms प्रति प्रकार लेता है। इसलिए यदि आवेदन के प्रवेश बिंदु में 8 निर्भरताएं हैं (एक श्रृंखला में) जिसके लिए उत्पन्न प्रॉक्सी की आवश्यकता है, तो एप्लिकेशन का स्टार्टअप समय 4.8 सेकेंड तक बढ़ जाता है। यह बहुत कुछ प्रतीत नहीं होता है, लेकिन उपयोगकर्ता के लिए, यह उम्र की तरह लगता है।डायनामिक प्रॉक्सी जेनरेशन स्पीड

इसे सुधारने के लिए कोई सलाह?

अद्यतन: 550ms और 750ms के बीच कहीं न कहीं

 var container = new WindsorContainer(); 
     container.Register(Component.For<Interceptor>()); // dummy IInterceptor...does nothing 
     container.Register(Component.For<IMyRepository, MyAbstractRepository>().Interceptors<Interceptor>()); 
     var t = DateTime.Now; 
     var instance = container.Resolve<IMyRepository>(); 
     Debug.WriteLine("Resolved in " + (DateTime.Now - t).TotalMilliseconds); 

आउटपुट:

मैं निम्नलिखित सांत्वना आवेदन के साथ समय पुन: पेश कर सकते हैं।

IMyRepository 30 इकाई प्रकारों (टी 4 टेम्पलेट द्वारा उत्पन्न) के लिए एक भंडार इंटरफ़ेस है। इसमें 31 IQueryables, 31 ओवरलोड लोड करें, और 31 ओवरलोड लोड करें। MyAbstractRepository आंशिक सार वर्ग है। यह वही 3 एक्स 31 विधियों की घोषणा करता है।

अगर मैं हटाने सभी बचाने के लिए और तरीकों को हटाएँ और केवल 31 IQueryables छोड़ दो और सार भंडार रजिस्टर नहीं है

container.Register(Component.For<IMyRepository>().Interceptors<Interceptor>()); 

मैं अभी भी प्रारंभिक पीढ़ी के लिए चारों ओर 250ms चलाते हैं।

यह एक बहुत ही (बहुत तेज) तेज मशीन है ... इसलिए असली दुनिया में कुछ भी ऊपर सूचीबद्ध संख्याओं की तुलना में धीमी गति से प्रदर्शन करेगा।

+1

यह हास्यास्पद है - जब तक आपके प्रकारों में सैकड़ों/हजारों विधियां नहीं हैं (या आप 20 यो मशीन पर कोड चला रहे हैं) जो मामला नहीं होना चाहिए। क्या आप पृथक प्रजनन बना सकते हैं? –

+0

मुझे पता है ... और यह 20 साल पुरानी मशीन नहीं है ... ऐसा लगता है कि यह होल्डअप (अन्य 5-10ms में उत्पन्न होता है) ... मैं अलग कर दूंगा और एक कोड नमूना प्रदान करूंगा। – Jeff

+1

यदि आपके पास निर्भरताएं हैं जहां उपयोग को स्थगित किया जा सकता है, तो आप आभासी प्रॉक्सी के पीछे निर्भरता ग्राफ के उस हिस्से को छिपाने में सक्षम हो सकते हैं। अवधारणा के अवलोकन के लिए यहां देखें: http://blog.ploeh.dk/2011/03/04/ComposeObjectGraphsWithConfidence.aspx –

उत्तर

1

आप प्रॉक्सी प्रारंभिकरण को एक अलग थ्रेड में निष्पादित करने में सक्षम हो सकते हैं, ताकि प्रॉक्सी उत्पन्न होने पर एप्लिकेशन स्वयं प्रारंभ हो सके। थ्रेडपूल में इसे क्यूइंग करने पर विचार करें।

प्रॉक्सी को एक सतत असेंबली फ़ाइल में संकलित करने का एक और विकल्प हो सकता है, जिसे डिस्क में सहेजा जाता है। ऐसा करने से पहले रन के बाद स्टार्टअप समय काफी कम हो जाएगा।

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

संबंधित मुद्दे