लाइन को आकर्षित करने के लिए - क्या LINQ को बहुत पसंद करना संभव है?

Question

मुझे हाल ही में LINQ मिला और इसे प्यार है। मुझे कई अवसर मिलते हैं जहां इसका उपयोग लांगहैंड संस्करण की तुलना में बहुत अधिक अभिव्यक्तिपूर्ण है लेकिन एक सहयोगी ने इस तकनीक का दुरुपयोग करने के बारे में एक टिप्पणी पारित की है, जिसमें अब मुझे दूसरा अनुमान लगाया गया है। यह मेरा परिप्रेक्ष्य है कि यदि कोई तकनीक कुशलता से काम करती है और कोड सुरुचिपूर्ण है तो इसका उपयोग क्यों न करें? क्या वह गलत है? मैं "लांगहैंड" प्रक्रियाओं को लिखने में अतिरिक्त समय व्यतीत कर सकता हूं और परिणामस्वरूप कोड कुछ एमएस तेज हो सकता है, यह 2-3 गुना अधिक कोड है और इसलिए 2-3 गुना अधिक संभावना है कि वहां बग हो सकते हैं।

मेरे विचार गलत है? क्या मैं LINQ का उपयोग करने के बजाय अपने कोड को लंबे समय से लिख रहा हूं? क्या यह LINQ के लिए डिज़ाइन नहीं किया गया था?

संपादित करें: मैं LINQ के ऑब्जेक्ट्स के बारे में बात कर रहा था, मैं LINQ से XML का उपयोग नहीं करता हूं और मैंने LINQ से SQL का उपयोग किया है, लेकिन मैं LINQ के रूप में उन स्वादों के साथ इतना मोहक नहीं हूं।

Answer 1

मुझे आपके विचार से सहमत होना है - यदि यह लिखने और सुरुचिपूर्ण करने के लिए अधिक कुशल है तो कुछ मिलीसेकंड क्या है। अतिरिक्त कोड लिखने से बगों को रेंगने के लिए और अधिक जगह मिलती है और यह अतिरिक्त कोड है जिसे परीक्षण करने की आवश्यकता होती है और अधिकांश इसे बनाए रखने के लिए अतिरिक्त कोड है। उस लड़के के बारे में सोचें जो आपके पीछे आ रहा है और अपना कोड बनाए रखेगा - वे आपको कोड लिखने के लिए धन्यवाद देने से पहले कोड पढ़ने के लिए सुरुचिपूर्ण आसान लिखने के लिए धन्यवाद देंगे जो कि कुछ एमएस तेज है!

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

Answer 2

आप प्रदर्शन के कुछ ही एमएस के लिए 2-3 बार अधिक कोड लिखने के बारे में बात करके अपने खुद के सवाल का जवाब देने जा रहे हैं। मेरा मतलब है, अगर आपकी समस्या डोमेन को उस गति की आवश्यकता है तो हाँ, यदि संभवतः नहीं। हालांकि, क्या यह वास्तव में प्रदर्शन के केवल कुछ एमएस है या यह> 5% या> 10% है। यह व्यक्तिगत मामले के आधार पर एक मूल्य निर्णय है।

Answer 3

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

आप प्रलेखन ले रहा शुरू करते हैं, तो यह आपकी स्थिति पर पुनर्विचार करने के लिए समय हो सकता है।

Answer 4

यह इन जहां यह अनुकूलन के स्वर्ण नियम याद रखना महत्वपूर्ण है तरह के मामलों:

1. डोंट वी डू इट
2. विशेषज्ञों के लिए: यह अभी तक

आप ऐसा मत करो चाहिए बिल्कुल नहीं के बारे में "दुरुपयोग" LINQ जब तक आप एक प्रदर्शन समस्या के कारण के रूप में स्पष्ट रूप से इसे indentify कर सकते हैं चिंता

Answer 5

कुछ भी पसंद है, इसका दुरुपयोग किया जा सकता है। जब तक आप इस तरह के

var v = List.Where(...); 
for(int i = 0; i < v.Count(); i++) 
{...} 

के रूप में स्पष्ट गरीब फैसलों से दूर रहने और समझ कैसे मतभेद निष्पादन काम करता है, तो यह सबसे पूरे अक्षरों में लिखावट रास्ता तुलना में बहुत धीमी होने के लिए नहीं जा रहा की संभावना है। एंडर्स हेजल्सबर्ग (सी # आर्किटेक्ट) के मुताबिक, सी # कंपाइलर लूप को अनुकूलित करने में विशेष रूप से अच्छा नहीं है, हालांकि यह अभिव्यक्ति पेड़ों को अनुकूलित करने और समानांतर करने में काफी बेहतर हो रहा है।समय में, यह एक पाश से अधिक प्रभावी हो सकता है। सूची <> के लिए प्रत्येक संस्करण वास्तव में लूप के रूप में तेज़ है, हालांकि मुझे वह लिंक नहीं मिल रहा है जो इसे साबित करता है।

पीएस मेरा व्यक्तिगत पसंदीदा foreach <> के कम ज्ञात चचेरे भाई IndexedForEach (उपयोग विस्तार विधि) है

List.IndexedForEach((p,i) => 
{ 
    if(i != 3) 
     p.DoSomething(i); 
}; 

Answer 6

इसकी संभव नहीं बहुत ज्यादा वस्तुओं को Linq प्यार करने के लिए, यह एक गुस्सा भयानक प्रौद्योगिकी है!

लेकिन गंभीरता से, जो कुछ भी आपके कोड को पढ़ने के लिए सरल बनाता है, बनाए रखने के लिए सरल है और जिस नौकरी के लिए इसका इरादा था, उसके बाद आप मूर्खतापूर्वक इसका इस्तेमाल नहीं कर सकते जितना आप कर सकते हैं।

Answer 7

हाँ आप LINQ बहुत ज्यादा प्यार कर सकते हैं - Single Statement LINQ RayTracer

आप कहाँ रेखा खींचना करते हैं? मैं LINQ का उपयोग इतना कहूंगा क्योंकि यह कोड को सरल और पढ़ने में आसान बनाता है।

जिस समय LINQ संस्करण को समझना मुश्किल हो जाता है, तब गैर-LINQ संस्करण स्वैप करने का समय होता है, और इसके विपरीत। संपादित करें: यह मुख्य रूप से LINQ-to-Objects पर लागू होता है क्योंकि अन्य LINQ स्वादों के अपने फायदे होते हैं।

Answer 8

लाइन कहां आकर्षित करें?

ठीक है, हम पहले से ही जानते हैं कि लिनक्स के ऑर्डरबी का उपयोग करने की तुलना में कम से कम अपने quicksort in linq को लागू करना एक बुरा विचार है।

Answer 9

मुझे पता चला है कि LINQ का उपयोग करके मेरे विकास में तेजी आई है और लूपों को पेश करने वाली बेवकूफ गलतियों से बचना आसान बना दिया है। मेरे पास ऐसे उदाहरण थे जहां LINQ का प्रदर्शन खराब था, लेकिन वह तब था जब मैं इसे एक पेड़ संरचना से एक्सेल फ़ाइल के लिए डेटा लाने जैसे चीजों के लिए उपयोग कर रहा था जिसमें लाखों नोड्स थे।

Answer 10

जबकि मैं देखता हूं कि LINQ एक कथन को पढ़ने के लिए कठिन कह सकता है, मुझे लगता है कि यह इस तथ्य से बहुत दूर है कि मेरी विधियां अब उन समस्याओं से सख्ती से संबंधित हैं जो वे हल कर रहे हैं और खर्च नहीं कर रहे हैं समर्पित लुकअप फ़ंक्शन के साथ लुकअप लूप या क्लटरिंग क्लास समेत समय।

LINQ के साथ चीजों को करने में थोड़ी देर लग गई, लूपिंग लुकअप के बाद, और जैसे, लंबे समय तक मुख्य विकल्प रहा है। मैं LINQ को एक और प्रकार की सिंटेक्टिक चीनी के रूप में देखता हूं जो एक ही काम को और अधिक सुरुचिपूर्ण तरीके से कर सकता है। अभी, मैं अभी भी प्रसंस्करण-भारी मिशन महत्वपूर्ण कोड में इसे टाल रहा हूं - लेकिन जब तक LINQ विकसित होता है तब तक प्रदर्शन में सुधार होता है।

Answer 11

LINQ के बारे में मेरी एकमात्र चिंता जुड़ने के कार्यान्वयन के साथ है।

जैसा कि मैंने जब this question जवाब देने के लिए कोशिश कर रहा है (और यह here की पुष्टि की है), कोड LINQ प्रदर्शन करने के लिए मिलती है (जरूरी, मुझे लगता है) अनुभवहीन उत्पन्न करता है निर्धारित: सूची में प्रत्येक आइटम के लिए, का में शामिल होने के माध्यम से एक रेखीय खोज करता है मिलान खोजने के लिए सूची में शामिल हो गए।

LINQ क्वेरी में शामिल होने के लिए अनिवार्य रूप से एक रैखिक-समय एल्गोरिदम को एक वर्ग-समय एल्गोरिदम में बदल देता है। यहां तक ​​कि यदि आपको लगता है कि समयपूर्व अनुकूलन सभी बुराइयों की जड़ है, तो ओ (एन) से ओ (एन^2) की कूद आपको रोक देनी चाहिए। (यह ओ (एन^3) है यदि आप किसी भी संग्रह में किसी अन्य संग्रह में शामिल होते हैं।)

इसके आसपास काम करना अपेक्षाकृत आसान है।उदाहरण के लिए, यह क्वेरी:

var list = from pr in parentTable.AsEnumerable() 
join cr in childTable.AsEnumerable() on cr.Field<int>("ParentID") equals pr.Field<int>("ID") 
where pr.Field<string>("Value") == "foo" 
select cr; 

SQL सर्वर में दो तालिकाओं में शामिल होने के समान है। लेकिन यह LINQ में बहुत अक्षम है: प्रत्येक पेरेंट पंक्ति के लिए where क्लॉज रिटर्न, क्वेरी पूरी बाल तालिका स्कैन करती है। इस क्वेरी (यहां तक ​​कि अगर आप एक unindexed मैदान पर शामिल हो रहे हैं, एसक्यूएल सर्वर एक hashtable का निर्माण करेगा तेजी लाने के लिए शामिल होने अगर यह कर सकते हैं कि LINQ के वेतन ग्रेड के बाहर एक छोटे से है।।)

, तथापि:

string fk = "FK_ChildTable_ParentTable"; 
var list = from cr in childTable.AsEnumerable() 
where cr.GetParentRow(fk).Field<string>("Value") == "foo" 
select cr; 

एक ही परिणाम उत्पन्न करता है, लेकिन यह केवल एक बार बच्चे की मेज स्कैन करता है।

यदि आप ऑब्जेक्ट्स के लिए LINQ का उपयोग कर रहे हैं, तो वही समस्याएं लागू होती हैं: यदि आप किसी भी महत्वपूर्ण आकार के दो संग्रहों में शामिल होना चाहते हैं, तो संभवतः आप शामिल वस्तु को खोजने के लिए एक और अधिक कुशल विधि को लागू करने पर विचार करने की आवश्यकता होगी, उदाहरण:

Dictionary<Foo, Bar> map = buildMap(foos, bars); 
var list = from Foo f in foos 
where map[f].baz == "bat" 
select f; 

Answer 12

LINQ कला की तरह हो सकता है। कोड को सुंदर बनाने के लिए इसका इस्तेमाल करते रहें।