एक कोड परिवर्तन पर निर्णय लेने के लिए आधार के रूप में बेंचमार्क

बिल कैनेडी ने अपने अद्भुत अल्टीमेट गो प्रोग्रामिंग कोर्स पर एक व्याख्यान में कहा:

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

मैं लंबे समय से एक व्यावहारिक उदाहरण के साथ प्रदर्शित करना चाहता हूं कि यह कैसे काम कर सकता है। और दूसरे दिन, मेरा ध्यान निम्नलिखित कोड पर गया, जिसे केवल इस तरह के उदाहरण के रूप में इस्तेमाल किया जा सकता है:

builds := store.Instance.GetBuildsFromNumberToNumber(stageBuild.BuildNumber, lastBuild.BuildNumber) tempList := model.BuildsList{} for i := len(builds) - 1; i >= 0; i-- { b := builds[i] b.PatchURLs = b.ReversePatchURLs b.ExtractedSize = b.RPatchExtractedSize tempList = append(tempList, b) } 

यहां, डेटाबेस से लौटाए गए बिल्ड स्लाइस के सभी तत्वों में, पैचपर्लस को ReversePatchURLs द्वारा बदल दिया जाता है, RPatchExtractedize द्वारा ExtractedSize और रिवर्स प्रदर्शन किया जाता है - तत्वों का क्रम बदल जाता है कि अंतिम तत्व पहला और पहला अंतिम बन जाता है।

मेरी राय में, स्रोत कोड पढ़ने के लिए थोड़ा जटिल है और इसे अनुकूलित किया जा सकता है। यह कोड एक सरल एल्गोरिथ्म करता है जिसमें दो तार्किक भाग होते हैं: स्लाइस तत्वों को बदलना और छांटना। लेकिन प्रोग्रामर के लिए इन दो घटकों को अलग करने के लिए, इसमें समय लगेगा।

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

लेकिन क्या होगा अगर हम न केवल कोड की धारणा को बेहतर बनाने का प्रबंधन करते हैं, बल्कि इसे काफी तेज भी करते हैं? यह पूरी तरह से अलग मामला है। आप कई वैकल्पिक एल्गोरिदम की पेशकश कर सकते हैं जो कोड में एम्बेडेड कार्यक्षमता का प्रदर्शन करते हैं।

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

 var tempList []*store.Build for _, build := range builds { build.PatchUrls, build.ExtractedSize = build.ReversePatchUrls, build.RPatchExtractedSize tempList = append([]*store.Build{build}, tempList...) } 

अंत से स्लाइस एन्यूमरेशन को हटाकर, हम स्पष्ट रूप से बदलते तत्वों (तीसरी पंक्ति) के संचालन और मूल सरणी (4 वीं पंक्ति) के रिवर्स के बीच प्रतिष्ठित हैं।

दूसरे विकल्प का मुख्य विचार तत्वों और छंटाई की विविधता को और अधिक विस्फोट करना है। सबसे पहले, हम तत्वों के माध्यम से सॉर्ट करते हैं और उन्हें बदलते हैं, और फिर एक अलग ऑपरेशन द्वारा स्लाइस को सॉर्ट करते हैं। इस विधि को स्लाइस के लिए छँटाई इंटरफ़ेस के अतिरिक्त कार्यान्वयन की आवश्यकता होगी, लेकिन यह पठनीयता को बढ़ाएगा और बदलते तत्वों से रिवर्स को पूरी तरह से अलग और अलग करेगा, और रिवर्स विधि निश्चित रूप से पाठक को वांछित परिणाम का संकेत देगा।

 var tempList []*store.Build for _, build := range builds { build.PatchUrls, build.ExtractedSize = build.ReversePatchUrls, build.RPatchExtractedSize } sort.Sort(sort.Reverse(sort.IntSlice(keys))) 

तीसरा विकल्प लगभग दूसरे की पुनरावृत्ति है, लेकिन सॉर्टिंग का उपयोग सॉर्टिंग के लिए किया जाता है, जो एक पंक्ति द्वारा कोड की मात्रा को बढ़ाता है, लेकिन सॉर्टिंग इंटरफ़ेस के अतिरिक्त कार्यान्वयन से बचा जाता है।

 for _, build := range builds { build.PatchUrls, build.ExtractedSize = build.ReversePatchUrls, build.RPatchExtractedSize } sort.Slice(builds, func(i int, j int) bool { return builds[i].Id > builds[j].Id }) 

पहली नज़र में, आंतरिक जटिलता के संदर्भ में, पुनरावृत्तियों की संख्या, अनुप्रयुक्त कार्य, प्रारंभिक कोड और पहला एल्गोरिथ्म करीब हैं; दूसरा और तीसरा विकल्प अधिक कठिन लग सकता है, लेकिन यह स्पष्ट रूप से कहना असंभव है कि चार विकल्पों में से कौन सा इष्टतम है।

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

परिशिष्ट निम्नानुसार काम करता है : यह या तो मौजूदा स्लाइस में एक नया तत्व जोड़ता है यदि इसकी क्षमता कुल लंबाई से अधिक है, या मेमोरी में एक नई स्लाइस के लिए जगह आरक्षित है, इसमें पहले स्लाइस से डेटा की प्रतिलिपि बनाना, दूसरे के डेटा को जोड़ना और परिणाम के रूप में एक नया लौटना। टुकड़ा।

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

एपेंड फ़ंक्शन की नई समझ को देखते हुए , प्रश्न का उत्तर: "क्या तेज़ होगा: एक तत्व को मौजूदा स्लाइस के अंत में जोड़ें या एक तत्व से एक स्लाइस में एक मौजूदा स्लाइस जोड़ें?" - पहले से अधिक पारदर्शी। यह माना जा सकता है कि दूसरे मामले में, पहले की तुलना में, अधिक मेमोरी आवंटन होगा, जो सीधे काम की गति को प्रभावित करेगा।

इसलिए हम आसानी से बेंचमार्क पर पहुँच गए। बेंचमार्क की मदद से, आप सबसे महत्वपूर्ण संसाधनों पर एल्गोरिथ्म के लोड का मूल्यांकन कर सकते हैं, जैसे रनटाइम और रैम।

आइए हम अपने सभी एल्गोरिदम के चारों का मूल्यांकन करने के लिए एक बेंचमार्क लिखें, साथ ही हम मूल्यांकन करेंगे कि क्या विकास हमें छंटनी की अस्वीकृति दे सकता है (यह समझने के लिए कि कुल समय में से कितना इसे छांटने में खर्च होता है)। बेंचमार्क कोड:

 package services import ( "testing" "sort" ) type Build struct { Id int ExtractedSize int64 PatchUrls string ReversePatchUrls string RPatchExtractedSize int64 } type Builds []*Build func (a Builds) Len() int { return len(a) } func (a Builds) Swap(i, j int) { a[i], a[j] = a[j], a[i] } func (a Builds) Less(i, j int) bool { return a[i].Id < a[j].Id } func prepare() Builds { var builds Builds for i := 0; i < 100000; i++ { builds = append(builds, &Build{Id: i}) } return builds } func BenchmarkF1(b *testing.B) { data := prepare() builds := make(Builds, len(data)) b.ResetTimer() for i := 0; i < bN; i++ { var tempList Builds copy(builds, data) for i := len(builds) - 1; i >= 0; i-- { b := builds[i] b.PatchUrls, b.ExtractedSize = b.ReversePatchUrls, b.RPatchExtractedSize tempList = append(tempList, b) } } } func BenchmarkF2(b *testing.B) { data := prepare() builds := make(Builds, len(data)) b.ResetTimer() for i := 0; i < bN; i++ { var tempList Builds copy(builds, data) for _, build := range builds { build.PatchUrls, build.ExtractedSize = build.ReversePatchUrls, build.RPatchExtractedSize tempList = append([]*Build{build}, tempList...) } } } func BenchmarkF3(b *testing.B) { data := prepare() builds := make(Builds, len(data)) b.ResetTimer() for i := 0; i < bN; i++ { copy(builds, data) for _, build := range builds { build.PatchUrls, build.ExtractedSize = build.ReversePatchUrls, build.RPatchExtractedSize } sort.Sort(sort.Reverse(builds)) } } func BenchmarkF4(b *testing.B) { data := prepare() builds := make(Builds, len(data)) b.ResetTimer() for i := 0; i < bN; i++ { copy(builds, data) for _, build := range builds { build.PatchUrls, build.ExtractedSize = build.ReversePatchUrls, build.RPatchExtractedSize } sort.Slice(builds, func(i int, j int) bool { return builds[i].Id > builds[j].Id }) } } func BenchmarkF5(b *testing.B) { data := prepare() builds := make(Builds, len(data)) b.ResetTimer() for i := 0; i < bN; i++ { copy(builds, data) for _, build := range builds { build.PatchUrls, build.ExtractedSize = build.ReversePatchUrls, build.RPatchExtractedSize } } } 

कमांड गो टेस्ट- बेंच के साथ बेंचमार्क लॉन्च करें =। -बेनचम्म

स्लाइस के लिए गणना परिणाम 10, 100, 1000, 10 000 और 100 000 तत्व नीचे ग्राफ में प्रस्तुत किए गए हैं, जहां F1 प्रारंभिक एल्गोरिथ्म है, F2 सरणी की शुरुआत के लिए तत्व का अतिरिक्त है, F3 सॉर्ट का उपयोग करता है। सॉर्ट करने के लिए इसका उपयोग करें। F4 सॉर्ट का उपयोग है । , F5 - छंटाई की अस्वीकृति।

ऑपरेशन का समय



स्मृति आवंटन की संख्या



जैसा कि आप ग्राफ से देख सकते हैं, आप सरणी को बढ़ा सकते हैं, लेकिन अंतिम परिणाम पहले से ही 10 तत्वों के एक स्लाइस पर अलग-थलग है। प्रस्तावित वैकल्पिक एल्गोरिदम (F2, F3, F4) में से कोई भी गति में मूल एल्गोरिथ्म (F1) से अधिक नहीं हो सकता है। इस तथ्य के बावजूद कि सभी लेकिन F2 में मूल की तुलना में कम मेमोरी आवंटन हैं। स्लाइस की शुरुआत के लिए एक तत्व के अतिरिक्त के साथ पहला एल्गोरिथ्म (F2) निकला सबसे अप्रभावी: जैसा कि अपेक्षित है, इसमें बहुत अधिक मेमोरी आवंटन हैं, इतना है कि उत्पाद विकास में इसका उपयोग करना बिल्कुल असंभव है। बिल्ट-इन रिवर्स सॉर्ट फ़ंक्शन (F3) का उपयोग करने वाला एल्गोरिथ्म मूल एक की तुलना में काफी धीमा है। और केवल छाँटे। लिस छँटाई एल्गोरिथ्म मूल एल्गोरिथ्म की गति में तुलनीय है, लेकिन यह इसके लिए थोड़ा नीचा है।

आप यह भी देख सकते हैं कि सॉर्टिंग (F5) से इनकार करना महत्वपूर्ण त्वरण देता है। इसलिए, यदि आप वास्तव में कोड को फिर से लिखना चाहते हैं, तो आप इस दिशा में जा सकते हैं, उदाहरण के लिए, डेटाबेस से प्रारंभिक बिल्ड स्लाइस को बढ़ाते हुए, अनुरोध में ASC के बजाय आईडी DESC द्वारा सॉर्टिंग का उपयोग करें। लेकिन एक ही समय में, हमें माना कोड सेक्शन की सीमाओं से परे जाने के लिए मजबूर किया जाता है, जो कई परिवर्तनों को शुरू करने के जोखिम को बढ़ाता है।

निष्कर्ष

बेंचमार्क लिखिए।

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

गो, पहली नज़र में, काफी सरल भाषा है। व्यापक 80 rule20 नियम यहां लागू होता है। ये 20% भाषा की आंतरिक संरचना की सूक्ष्मताओं का प्रतिनिधित्व करते हैं, जिनमें से ज्ञान अनुभवी डेवलपर से नौसिखिया को अलग करता है। अपने प्रश्नों को हल करने के लिए बेंचमार्क लिखने की प्रथा एक उत्तर और गो भाषा की आंतरिक संरचना और सिद्धांतों की गहरी समझ पाने के लिए सबसे सस्ते और प्रभावी तरीकों में से एक है।