क्या एकता धीमी है? सावधानी LINQ

अक्सर कहा जाता है कि एकता धीमी है। लेकिन कितना? मैं एक पिक्सेल स्टूडियो एप्लिकेशन विकसित कर रहा हूं, यह एक पिक्सेल आर्ट एडिटर है। उसके लिए, मैंने GIF प्रारूप के अपने कार्यान्वयन को लिखा। सबसे अधिक समय लेने वाला ऑपरेशन GIF कोडिंग है, जिसका नाम है LZW कम्प्रेशन अल्गोरिथम। आइए देखें कि एकता इसे कैसे संभालती है।


सबसे पहले, मैं तुरंत स्पष्ट कर दूंगा कि मुझे अपनी लाइब्रेरी क्यों लिखनी थी। हां, सब कुछ सरल है, System.Windows.Media.Imaging पुस्तकालय, जिसमें अद्भुत GifBitmapEncoder शामिल है, एकता से जुड़ा नहीं हो सकता। इसलिए मैंने GIF के बारे में हब पर लेख पढ़ा, विनिर्देश लिया और लाठी के साथ मेरा GIF बनाया।

बेशक, मैंने कंसोल स्टूडियो में विज़ुअल स्टूडियो में लाइब्रेरी लिखना और डिबग करना शुरू कर दिया। मैं इस क्षण को छोड़ दूंगा, यह उबाऊ था और डीबग करने के लिए लंबा था, इसमें 3 दिन लगे। इस तरह के एल्गोरिदम में, मेरे पास अनुभव नहीं था, आमतौर पर खेल कर रहे थे। ठीक है, पुस्तकालय तैयार है। उदाहरण के लिए, 200 फ्रेम में एक परीक्षण "भारी" जीआईएफ और 256x256 का रिज़ॉल्यूशन 15 सेकंड में एन्कोड किया गया है (राइज़ेन 7, निश्चित रूप से, मेरे हार्डवेयर पर)। बहुत कुछ, मैंने सोचा, और सज्जन के हाथ से मैंने संपीड़न प्रक्रिया को समानांतर बनाया (जैसे एकता को धागे का समर्थन करना चाहिए)। परीक्षण GIF 5 सेकंड में एन्कोड हो गया। बहुत बढ़िया!

अगर यह काम करता है, तो जांच करने के लिए एकता में सभी स्रोत कोड की प्रतिलिपि बनाना। टेस्ट GIF कोडिंग में 120 सेकंड लगते हैं। मल्टी-थ्रेडेड मोड में (हां, थ्रेड इन यूनिटी काम करते हैं, मुख्य बात यह नहीं है कि यूआई को छूएं) एक gif को 180 सेकंड के लिए एन्कोडिंग। Facepalm।

Google - समस्या, यह पता चला है, आम है। इसी तरह की रिपोर्टों के अनुसार, एकता में एल्गोरिदम कोड 10-20 बार धीमा चलता है। यह कथित रूप से एक और कचरा संग्रह कार्यान्वयन और धूमिल संपादक ओवरहेड के साथ जुड़ा हुआ है। असेंबली (विंडोज, एंड्रॉइड) में स्थिति समान है। उदाहरण के लिए, .exe असेंबली में, यह 20% तक थोड़ा तेज़ काम करता है।

पाठकों से सवाल - क्या मैं कुछ गलत कर रहा हूं, या कोई समस्या है?

GIF के कार्यान्वयन के लिए लिंक, जो रुचि रखते हैं: GitHub । पुस्तकालय C # संस्करण 6 और .NET 3.5 के तहत लिखा गया था ताकि एकता के पुराने संस्करणों के साथ संगत हो सके। प्रोजेक्ट को .NET 4.0 पर स्विच किया जा सकता है, फिर थ्रेडपूल बहुत तेजी से काम करेगा।

UPD: टिप्पणियों के लिए धन्यवाद! सब कुछ थोड़ा भ्रमित हो गया: ताले के साथ दोनों धागे, और एक वक्र कार्यान्वयन। इसलिए मैंने एक साधारण मामला तैयार किया - लिनक्यू में एक सरणी के माध्यम से चलने का संचालन। अर्थात्, ऐसा ऑपरेशन LZW संपीड़न के दौरान किया जाता है (केवल शब्दकोश में एक महत्वपूर्ण जाँच है)।



हम कंसोल एप्लिकेशन में निष्पादित करते हैं - 5 एमएस।
एकता में चल रहा है - 2100 एमएस।

UPD: समस्या का एक भाग LINQ में पाया जाता है। उदाहरण के लिए, कॉन्टेन्स को कॉल करना Array.IndexOf की तुलना में कई गुना धीमा है। LINQ बढ़िया है, यह समय बचाता है और कोड को और अधिक सुंदर बनाता है। लेकिन वस्तुओं के बड़े सरणियों के साथ काम करने के रूप में ऐसे लागू कार्यों में नहीं। यह एकता में एक विशिष्ट LINQ कार्यान्वयन पर लागू होता है।

UPD: LZW कम्प्रेशन अल्गोरिथम को ऑप्टिमाइज़ किया, डिक्शनरी में स्ट्रिंग कीज़ को हटाया। जहां संभव हो बड़े संग्रह के लिए LINQ को हटा दिया। मैंने मल्टीथ्रेडिंग के कार्यान्वयन को नहीं छुआ। और सब कुछ उड़ गया, यहां तक ​​कि एंड्रॉइड पर भी। बेशक, कंसोल एप्लिकेशन की गति के बीच अंतर बना हुआ है, लेकिन यह इतना महत्वपूर्ण नहीं है।

कोड को अनुकूलित करने और चर्चा में सभी प्रतिभागियों को मदद करने के लिए WNeZRoS के लिए विशेष धन्यवाद! हालांकि LINQ में ब्रेक का कारण अनसुलझा है।