सिस्टम। रिफ्लेक्शन बनाम जेनेरिक - प्रदर्शन

Question

मैं एक सर्वर अनुप्रयोग पर विधियों का एक सेट लिखने वाला हूं जो टीसीपी सॉकेट से प्राप्त संदेश लेता है, उन्हें एन्कोड/डीकोड करता है, और उन्हें एन्क्रिप्ट/डिक्रिप्ट करता है। इस तरह के Encode<T>(...) where T : IMessage रूप 1. मेक तरीकों कि जेनरिक का उपयोग करें, और उसके बाद एनकोडर लागू:

को ध्यान में रखते संदेशों विशेष प्रकार के रूप में परिभाषित कर रहे हैं, गुण और कुल लंबाई के अपने स्वयं के सेट के साथ प्रत्येक, मैं नीचे दिए समाधान के लिए चुनते करने की जरूरत है/प्रत्येक प्रकार के संदेश के लिए डिकोडर और ResolveEncoder<T> है जो वांछित संदेश या के लिए एन्कोडर लेगा 2. किसी भी प्रकार का संदेश उपयोग करता है, जब तक यह IMessage लागू करता है, जैसे Encode(IMessage message), और सिस्टम का उपयोग करें। सब कुछ निर्धारित करने के लिए प्रतिबिंब मुझे इसके बारे में जानना है।

मुझे समाधान # 2 करने में अधिक दिलचस्पी है क्योंकि यह मेरा कोड 30 गुना छोटा बनाता है। हालांकि, मुझे चिंता है कि संपत्तियों का निरंतर प्रतिबिंब प्रदर्शन को प्रभावित करेगा या नहीं। अब जब मैं परियोजना को पूरा करने के लिए सीमित हूं, तो मैं वास्तव में "प्रयोग" नहीं कर सकता।

मैं किसी भी व्यक्तिगत अनुभव या लिंक के साथ लिंक के साथ आभारी हूं कि समाधान के साथ प्रदर्शन कैसे होता है।

Answer 1

प्रतिबिंब पर्याप्त तेज़ हो सकता है। लेकिन सही ढंग से लागू करने की जरूरत है।

परावर्तन प्रदर्शन - Improving performance reflection , what alternatives should I consider

-

फास्ट एंड लाइट कार्य

typeof 
Object.GetType 
typeof == Object.GetType 
Type equivalence APIs (including typehandle operator overloads) 
get_Module 
get_MemberType 
Some of the IsXX predicate APIs 
New token/handle resolution APIs in the .NET Framework 2.0 

महंगे कार्य

GetXX APIs (MethodInfo, PropertyInfo, FieldInfo, and so on) 
GetCustomAttributes 
Type.InvokeMember 
Invoke APIs (MethodInfo.Invoke, FieldInfo.GetValue, and so on) 
get_Name (Name property) 
Activator.CreateInstance 

Source - Dodge Common Performance Pitfalls to Craft Speedy Applications

MethodInfo में तेजी लाने के किया जा सकता है

अच्छा लिंक:
How costly is .NET reflection?
http://www.codeproject.com/Articles/18450/HyperDescriptor-Accelerated-dynamic-property-acces

Answer 2

जेनरिक संकलन समय पर बंधे हैं, और सामान्य प्रकार के रूप में प्रदर्शन के रूप में होंगे। प्रतिबिंब एक बड़ी कीमत पर आएगा।

Answer 3

अब जब मैं परियोजना को पूरा करने के लिए सीमित हूं, तो मैं वास्तव में "प्रयोग" नहीं कर सकता।

तब आपकी असली बाधा प्रदर्शन नहीं है, बल्कि आप समय सीमा में कोड और परीक्षण और डीबग कर सकते हैं। मान लीजिए कि आपका दावा है कि प्रतिबिंब संस्करण 30x छोटा है, ऐसा लगता है कि आपको इसके प्रति दुबला होना चाहिए।

हालांकि, पांच अंक:

1. मुझे शक है कि 30x सही अनुमान है, यह शायद बहुत छोटे हैं।
2. जेनिक्स का उपयोग करने से प्रतिबिंब कम प्रदर्शनकारी होगा। इसके बारे में कोई सवाल नहीं है।
3. "हालांकि, मुझे चिंता है कि संपत्तियों का निरंतर प्रतिबिंब प्रदर्शन को प्रभावित करेगा या नहीं।" आप आक्रामक रूप से PropertyInfo एस को कैश करके और प्रतिबिंब द्वारा लोड नहीं करते हैं कि आप इसे कुछ कम कर सकते हैं।
4. आप अभिव्यक्ति पेड़ों का उपयोग करके प्रतिबिंब के समान कुछ कर सकते हैं, और आपको ऐसा करने से एक महत्वपूर्ण प्रदर्शन बढ़ावा मिलेगा। यहां एक blog post है जो आपको इस समस्या पर सही दिशा में धक्का देगा। हालांकि, अगर आप पहले से ही अभिव्यक्ति के पेड़ों के साथ काम करने से परिचित नहीं हैं, तो अपना समय बाधा दी गई है, यह एक ऐसी अवधारणा का उपयोग करके कोडिंग, परीक्षण और डिबगिंग करने का जोखिम है जिसे आप परिचित नहीं हैं।
5. क्या आप सुनिश्चित हैं कि यह भी एक प्रदर्शन बाधा है? यदि नेटवर्क विलंबता यहां पर हावी है, तो यह मुझे सदमा नहीं देगा, और आप समय-समय पर अनुकूलन कर रहे हैं।

Answer 4

यदि प्रदर्शन अपने चिंता का विषय है, संदेश के प्रत्येक प्रकार के लिए DynamicMethod पैदा करने पर विचार करें। कोड जो गतिशील विधि उत्पन्न करेगा सभी संदेश प्रकारों के लिए समान होगा (जैसे कि यह प्रतिबिंब के साथ होगा), लेकिन एक बार गतिशील विधि उत्पन्न हो जाएगी, आपके पास प्रतिबिंब का कोई प्रदर्शन हिट नहीं होगा। नुकसान यह है कि कोड लिखना कठिन होता है और डीबग करना अधिक मुश्किल होता है, इसलिए यदि आप समय पर दबाव में हैं तो यह सबसे अच्छा विकल्प नहीं हो सकता है।

Answer 5

एक दृष्टिकोण जो प्रायः सहायक है, स्थिर जेनेरिक वर्गों के साथ प्रतिबिंब का उपयोग करना है। यह EqualityComparer<T>.Default जैसी चीजों से लिया गया दृष्टिकोण है। मूलतः, यह क्या होता है किसी विशेष प्रकार T के लिए, EqualityComparer<T>.Default का पहला संदर्भ प्रतिबिंब का उपयोग करने के निर्धारित प्रकार T लागू करता IComparable<T> और या तो IEqualityComparer<T> के एक कार्यान्वयन एक है कि एक स्वेच्छापूर्ण T पर चल रही है और Object.Equals का उपयोग करता है, वरना निर्माण करना होगा कि जो बाधा T से IEqualityComparer<T> और IEqualityComparer<T>.Equals का उपयोग करता है। उस उद्देश्य के लिए प्रतिबिंब का उपयोग कुछ हद तक धीमा है, लेकिन इसे किसी विशेष प्रकार T के लिए केवल एक बार किया जाना चाहिए। एक बार कार्यान्वयन का निर्माण हो जाने के बाद, इसे EqualityComparer<T> के स्थिर क्षेत्र में संग्रहीत किया जाएगा, इसलिए उस प्रकार के लिए डिफ़ॉल्ट तुलनाकर्ता प्राप्त करने के लिए भविष्य के अनुरोधों को पहले से निर्मित IEqualityComparer<T> कार्यान्वयन का उपयोग करने में सक्षम हो जाएगा।

यह दृष्टिकोण जेनिक्स की गति को उन चीजों को करने के लिए लचीलापन के साथ जोड़ता है जिनके लिए जेनिक्स अकेले पर्याप्त नहीं हैं।

Answer 6

वर्तमान कोड इस करता है:

protected void Decode<T>(Action<BinaryReader> action, byte[] buffer) {...} 

बनाता MemoryStream धारा। स्ट्रीम पर बाइनरी रीडर रीडर बनाता है। और फिर कार्रवाई (पाठक) करता है।

अब मान लीजिए कि हमारे पास HelloMessage.cs है जिसमें केवल दो गुण हैं, एक बाइट आईडी और int Descriptor।

public HelloMessage Decode(byte[] buffer) 
{ 
    var message = new HelloMessage(); 
    Decode<HelloMessage>(reader => 
     { message.Id = reader.ReadByte(); 
      message.Descriptor = reader.ReadInt32(); 
     }, buffer); 
    return message; 
} 

यह वास्तव में अच्छी तरह से किया जाता है, तथापि, वहाँ गए संदेशों के बारे में 15 प्रकार के है, और प्रत्येक प्रकार यह डिकोड और एनकोड कार्यान्वयन के साथ खुद xxxMessageCodec.cs है है: डिकोडर वर्ग HelloMessageCodec.cs की डिकोड विधि इस तरह दिखता है , प्रत्येक संपत्ति को मैन्युअल रूप से कार्य प्रतिनिधि के भीतर पास किया जाता है।

अब मुझे एन्क्रिप्शन करना है, जिसका अर्थ है, क्या मुझे इस पैटर्न का पालन करना चाहिए, मुझे 15 अलग-अलग संदेश एन्क्रिप्टर बनाना होगा।

मैंने पहले से ही सभी कोडेक कोड को समाधान # 2 (प्रतिबिंब के साथ) में फिर से काम किया है, और 15 x 2 फ़ंक्शंस रखने के बजाय, मेरे पास केवल 2 फ़ंक्शंस हैं + अंतर्निहित स्तर केवल दो फ़ंक्शंस हैं जो उनके गुणों और इनवॉइस द्वारा संदेशों को संसाधित करते हैं टाइपबेट, ReadInt32, ... टाइपफ संपत्ति के आधार पर।

तो, मैंने काम किया है, लेकिन मेरे पास प्रदर्शन का परीक्षण करने के लिए पर्याप्त समय नहीं है क्योंकि मुझे एन्क्रिप्शन पर काम करने के साथ आगे बढ़ना है। मुझे आगे बढ़ने के लिए दो समाधानों में से एक चुनना है, और मुझे नींद की समस्या है कि क्या छोटा समाधान (प्रतिबिंब एक) मुझे बाद में चेहरे पर वापस लाएगा :)