मुझे हमेशा प्रदर्शन की परवाह है। मुझे ठीक-ठीक पता नहीं है कि क्यों। लेकिन मैं सिर्फ धीमी सेवाओं और कार्यक्रमों से नाराज हो जाता हूं। लगता है मैं अकेला नहीं हूँ ।

ए / बी परीक्षणों में, हमने 100 मिलीसेकंड की वृद्धि में पृष्ठों के उत्पादन को धीमा करने की कोशिश की और पाया कि बहुत कम देरी से राजस्व में एक महत्वपूर्ण गिरावट आती है। - ग्रेग लिंडेन, Amazon.com

अनुभव से, कम उत्पादकता दो तरीकों में से एक में प्रकट होती है:

• छोटे पैमाने पर अच्छा प्रदर्शन करने वाले संचालन उपयोगकर्ताओं की बढ़ती संख्या के साथ अविश्वसनीय हो जाते हैं। आमतौर पर ये O (N) या O (N are) ऑपरेशन होते हैं। जब उपयोगकर्ता का आधार छोटा होता है, तो सब कुछ ठीक काम करता है। उत्पाद बाजार में लाने की जल्दी में है। जैसे-जैसे आधार बढ़ता है, अधिक से अधिक अप्रत्याशित रोग संबंधी स्थितियां पैदा होती हैं - और सेवा बंद हो जाती है।
  
• उप-रूपी काम के कई व्यक्तिगत स्रोत, "एक हजार कटौती से मौत।"

अपने अधिकांश करियर के लिए, मैंने या तो पायथन के साथ डेटा साइंस का अध्ययन किया या गो पर सेवाओं का निर्माण किया। दूसरे मामले में, मुझे अनुकूलन में बहुत अधिक अनुभव है। गो आमतौर पर मेरे द्वारा लिखी जाने वाली सेवाओं में अड़चन नहीं है - डेटाबेस प्रोग्राम अक्सर I / O द्वारा सीमित होते हैं। हालांकि, मशीन लर्निंग बैच पाइपलाइनों में मैंने विकसित किया, प्रोग्राम अक्सर सीपीयू द्वारा सीमित होता है। यदि Go प्रोसेसर का बहुत अधिक उपयोग करता है, तो विभिन्न रणनीतियाँ हैं।

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

शुरू करने से पहले

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

यदि कोड बेंचमार्क के साथ बहुत संगत नहीं है, तो बस उस चीज़ से शुरू करें जिसे मापा जा सकता है। आप रनटाइम / पीटीआई के साथ कोड को मैन्युअल रूप से प्रोफाइल कर सकते हैं।

तो चलिए शुरू करते है!

पहले चयनित ऑब्जेक्ट्स का पुन: उपयोग करने के लिए Sync.Pool का उपयोग करें

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

var bufpool = sync.Pool{ New: func() interface{} { buf := make([]byte, 512) return &buf }} 

उसके बाद, आप पूल से Put() और Put() कर सकते हैं जब आप कर रहे हों।

 // sync.Pool returns a interface{}: you must cast it to the underlying type // before you use it. b := *bufpool.Get().(*[]byte) defer bufpool.Put(&b) // Now, go do interesting things with your byte buffer. buf := bytes.NewBuffer(b) 

बारीकियां हैं। 1.13 जाने से पहले, पूल को हर कचरा संग्रह के साथ साफ किया गया था। यह उन कार्यक्रमों के प्रदर्शन पर प्रतिकूल प्रभाव डाल सकता है जो बहुत सारी मेमोरी आवंटित करते हैं। 1.13 तक, ऐसा लगता है कि अधिक वस्तुएं जीसी के बाद बच जाती हैं ।

!!! किसी ऑब्जेक्ट को पूल में वापस करने से पहले, संरचना फ़ील्ड को रीसेट करना सुनिश्चित करें।

यदि आप नहीं करते हैं, तो आप उस पूल से एक गंदी वस्तु प्राप्त कर सकते हैं जिसमें पिछले उपयोग का डेटा है। यह एक गंभीर सुरक्षा जोखिम है!

 type AuthenticationResponse { Token string UserID string } rsp := authPool.Get().(*AuthenticationResponse) defer authPool.Put(rsp) // If we don't hit this if statement, we might return data from other users! if blah { rsp.UserID = "user-1" rsp.Token = "super-secret" } return rsp 

शून्य मेमोरी की गारंटी देने का एक सुरक्षित तरीका यह है कि यह स्पष्ट रूप से करें:

 // reset resets all fields of the AuthenticationResponse before pooling it. func (a* AuthenticationResponse) reset() { a.Token = "" a.UserID = "" } rsp := authPool.Get().(*AuthenticationResponse) defer func() { rsp.reset() authPool.Put(rsp) }() 

एकमात्र मामला जब यह समस्या नहीं है जब आप लिखी गई सटीक मेमोरी का उपयोग करते हैं। उदाहरण के लिए:

 var ( r io.Reader w io.Writer ) // Obtain a buffer from the pool. buf := *bufPool.Get().(*[]byte) defer bufPool.Put(&buf) // We only write to w exactly what we read from r, and no more. nr, er := r.Read(buf) if nr > 0 { nw, ew := w.Write(buf[0:nr]) } 

एक बड़े मानचित्र के लिए कुंजियों के रूप में युक्त संरचनाओं का उपयोग करने से बचें

फूह, मैं भी वाचाल था। मुझे क्षमा करें। वे अक्सर (मेरे पूर्व सहयोगी फिल पर्ल सहित) बड़े प्रदर्शन के साथ गो प्रदर्शन के बारे में बात करते थे। कचरा संग्रह के दौरान, रनटाइम ऑब्जेक्ट्स को पॉइंटर्स से स्कैन करता है और उन्हें ट्रैक करता है। यदि आपके पास बहुत बड़ा मानचित्र map[string]int , तो जीसी को प्रत्येक पंक्ति की जांच करनी चाहिए। यह हर कचरा संग्रह के साथ होता है, क्योंकि लाइनों में संकेत होते हैं।

इस उदाहरण में, हम 10 मिलियन तत्वों को लिखते हैं map[string]int लिए और कचरा संग्रह की अवधि को मापते हैं। हम ढेर से मेमोरी आवंटन की गारंटी देने के लिए पैकेज क्षेत्र में अपना नक्शा आवंटित करते हैं।

 package main import ( "fmt" "runtime" "strconv" "time" ) const ( numElements = 10000000 ) var foo = map[string]int{} func timeGC() { t := time.Now() runtime.GC() fmt.Printf("gc took: %s\n", time.Since(t)) } func main() { for i := 0; i < numElements; i++ { foo[strconv.Itoa(i)] = i } for { timeGC() time.Sleep(1 * time.Second) } } 

कार्यक्रम को चलाने पर, हम निम्नलिखित देखेंगे:

  inthash → go इंस्‍टॉल && inthash
 gc लिया: 98.726321ms
 gc लिया: 105.524633ms
 gc लिया: 102.829451ms
 gc लिया: 102.71908ms
 gc लिया: 103.084104ms
 gc लिया: 104.821989ms 

कंप्यूटर देश में यह काफी लंबा समय है!

अनुकूलन करने के लिए क्या किया जा सकता है? हर जगह पॉइंटर्स को हटाना एक अच्छा विचार है, ताकि कचरा कलेक्टर को लोड न किया जाए। लाइनों में संकेत हैं ; तो चलिए इसे map[int]int रूप में लागू करते हैं।

 package main import ( "fmt" "runtime" "time" ) const ( numElements = 10000000 ) var foo = map[int]int{} func timeGC() { t := time.Now() runtime.GC() fmt.Printf("gc took: %s\n", time.Since(t)) } func main() { for i := 0; i < numElements; i++ { foo[i] = i } for { timeGC() time.Sleep(1 * time.Second) } } 

कार्यक्रम को फिर से चलाना, हम देखते हैं:

  inthash → go इंस्‍टॉल && inthash
 gc लिया: 3.608993ms
 gc लिया: 3.926913ms
 gc लिया: 3.955706ms
 gc लिया: 4.063795ms
 gc लिया: 3.91519ms
 gc लिया: 3.75226ms 

बहुत बेहतर। हमने 35 बार कचरा संग्रहण में तेजी लाई है। जब उत्पादन में उपयोग किया जाता है, तो कार्ड में डालने से पहले तार को पूर्णांक में हैश करना आवश्यक होगा।

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

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

रनटाइम परावर्तन से बचने के लिए कोड जनरेशन की मार्कशीट

JSON जैसे विभिन्न सीरियलाइज़ेशन प्रारूपों में अपनी संरचना को मार्शेल करना और अनमर्श करना, एक विशिष्ट ऑपरेशन है, खासकर जब मैट्रोज़ सर्विसेज़ बनाते हैं। कई microservices के लिए, यह आमतौर पर एकमात्र काम है। json.Marshal और json.Unmarshal जैसे कार्य बाइट्स और इसके विपरीत में संरचना क्षेत्रों को क्रमबद्ध करने के लिए रनटाइम में प्रतिबिंब पर भरोसा करते हैं। यह धीरे-धीरे काम कर सकता है: प्रतिबिंब स्पष्ट कोड जितना कुशल नहीं है।

हालाँकि, अनुकूलन विकल्प हैं। JSON मार्शलिंग मैकेनिक्स कुछ इस तरह दिखता है:

 package json // Marshal take an object and returns its representation in JSON. func Marshal(obj interface{}) ([]byte, error) { // Check if this object knows how to marshal itself to JSON // by satisfying the Marshaller interface. if m, is := obj.(json.Marshaller); is { return m.MarshalJSON() } // It doesn't know how to marshal itself. Do default reflection based marshallling. return marshal(obj) } 

यदि हम JSON में मार्शलाइज़ेशन प्रक्रिया को जानते हैं, तो हमारे पास रनटाइम में प्रतिबिंब से बचने के लिए एक सुराग है। लेकिन हम सभी मार्शलाइज़ेशन कोड को मैन्युअल रूप से लिखना नहीं चाहते हैं, इसलिए हमें क्या करना चाहिए? कंप्यूटर को यह कोड जनरेट करने दें! कोड जेनरेटर जैसे कि ईजीसन संरचना को देखते हैं और अत्यधिक अनुकूलित कोड उत्पन्न करते हैं जो कि वर्तमान में json.Marshaller जैसे मौजूदा json.Marshaller इंटरफेस के साथ पूरी तरह से अनुकूल है।

पैकेज डाउनलोड करें और $file.go में निम्न कमांड $file.go , जिसमें ऐसी संरचनाएं हैं जिनके लिए आप कोड उत्पन्न करना चाहते हैं।

  easyjson -all $ file.go 

फ़ाइल $file_easyjson.go उत्पन्न की जानी चाहिए। चूंकि easyjson आपके लिए json.Marshaller इंटरफ़ेस लागू किया है, इसलिए इन कार्यों को प्रतिबिंब के बजाय डिफ़ॉल्ट रूप से कहा जाएगा। बधाई: आपने तीन बार अपना JSON कोड त्वरित किया। उत्पादकता को और बढ़ाने के लिए कई तरकीबें हैं।

मैं इस पैकेज की सिफारिश करता हूं क्योंकि मैंने इसे पहले खुद इस्तेमाल किया है, और सफलतापूर्वक। लेकिन सावधान रहें। कृपया इसे सबसे तेज JSON पैकेज के बारे में मेरे साथ आक्रामक बहस शुरू करने के निमंत्रण के रूप में न लें।

संरचना में परिवर्तन होने पर मार्शिंग कोड को पुन: जेनरेट करना सुनिश्चित करें। यदि आप ऐसा करना भूल जाते हैं, तो नए जोड़े गए क्षेत्रों को क्रमबद्ध नहीं किया जाएगा, जिससे भ्रम पैदा होगा! आप इन कार्यों के लिए go generate उपयोग कर सकते हैं। संरचनाओं के साथ सिंक्रनाइज़ेशन बनाए रखने के लिए, मैं पैकेज के रूट पर generate.go को स्थान देना पसंद generate.go हूं, जो सभी पैकेज फ़ाइलों के लिए go generate करता है: यह तब मदद कर सकता है जब आपके पास बहुत सारी फाइलें होती हैं जिन्हें इस तरह के कोड उत्पन्न करने की आवश्यकता होती है। मुख्य टिप: यह सुनिश्चित करने के लिए कि संरचनाएं अद्यतन हैं, कॉल सीआई में go generate करें और जांचें कि पंजीकृत कोड के साथ कोई अंतर नहीं है।

तार का उपयोग करें

गो में, तार अपरिवर्तनीय हैं: उन्हें केवल-पढ़ने के लिए बाइट्स के रूप में सोचें। इसका मतलब है कि हर बार जब आप एक स्ट्रिंग बनाते हैं, तो आप मेमोरी आवंटित करते हैं और संभावित रूप से कचरा संग्रहकर्ता के लिए अधिक काम पैदा करते हैं।

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

दो दृष्टिकोणों के प्रदर्शन की तुलना करें:

 // main.go package main import "strings" var strs = []string{ "here's", "a", "some", "long", "list", "of", "strings", "for", "you", } func buildStrNaive() string { var s string for _, v := range strs { s += v } return s } func buildStrBuilder() string { b := strings.Builder{} // Grow the buffer to a decent length, so we don't have to continually // re-allocate. b.Grow(60) for _, v := range strs { b.WriteString(v) } return b.String() } 

 // main_test.go package main import ( "testing" ) var str string func BenchmarkStringBuildNaive(b *testing.B) { for i := 0; i < bN; i++ { str = buildStrNaive() } } func BenchmarkStringBuildBuilder(b *testing.B) { for i := 0; i < bN; i++ { str = buildStrBuilder() } 

यहाँ मेरे मैकबुक प्रो पर परिणाम हैं:

  strbuild -> go test -bench =।  -benchmem
 goos: डार्विन
 goarch: amd64
 pkg: github.com/sjwhitworth/perfblog/strbuild
 BenchmarkStringBuildNaive-8 5,000,000 255 ns / op 216 B / op 8 allocs / op
 बेंचमार्कस्ट्रिंगबील्डबुल्ट -8 20,000,000 54.9 ns / op 64 B / op 1 ऑलोकोज़ और प्रति ऑप्स 

जैसा कि आप देख सकते हैं, strings.Builder 4.7 गुना तेज है, आठ बार कम आवंटन का कारण बनता है और चार गुना कम मेमोरी लेता है।

जब प्रदर्शन मायने रखता है, strings.Builder उपयोग करें। सामान्य तौर पर, मैं इसे हर जगह उपयोग करने की सलाह देता हूं, जिसमें इमारत के सबसे तुच्छ मामलों को छोड़कर।

Fmt के बजाय strconv का उपयोग करें

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

fmt मूल रूप से फ़ंक्शन तर्कों के रूप में interface{} लेता है। दो कमियां हैं:

• आप प्रकार की सुरक्षा खो रहे हैं। मेरे लिए यह बहुत महत्वपूर्ण है।
  
• इससे आवश्यक स्राव की मात्रा बढ़ सकती है। एक पॉइंटर के बिना एक interface{} रूप में पास करना interface{} आमतौर पर ढेर आवंटन में परिणाम होता है। यह ब्लॉग पोस्ट बताता है कि ऐसा क्यों है।
• निम्नलिखित कार्यक्रम प्रदर्शन में अंतर दिखाता है:
  
  

   // main.go package main import ( "fmt" "strconv" ) func strconvFmt(a string, b int) string { return a + ":" + strconv.Itoa(b) } func fmtFmt(a string, b int) string { return fmt.Sprintf("%s:%d", a, b) } func main() {} 

  
  

   // main_test.go package main import ( "testing" ) var ( a = "boo" blah = 42 box = "" ) func BenchmarkStrconv(b *testing.B) { for i := 0; i < bN; i++ { box = strconvFmt(a, blah) } a = box } func BenchmarkFmt(b *testing.B) { for i := 0; i < bN; i++ { box = fmtFmt(a, blah) } a = box } 

  
  मैकबुक प्रो पर बेंचमार्क:
  
  

    strfmt → go test -bench =।  -benchmem
   goos: डार्विन
   goarch: amd64
   pkg: github.com/sjwhitworth/perfblog/strfmt
   BenchmarkStrconv-8 30,000,000 39.5 ns / op 32 B / op 1 allocs / op
   बेंचमार्कएफएमटी -8 10,000,000 143 ns / op 72 B / op 3 allocs / op 

  
  जैसा कि आप देख सकते हैं, स्ट्रेंक विकल्प 3.5 गुना तेज है, तीन बार कम आवंटन का कारण बनता है और आधी मेमोरी लेता है।
  
  

  पुनर्वितरण से बचने के लिए स्लाइस टैंक को आवंटित करें

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

   type slice struct { // pointer to underlying data in the slice. data uintptr // the number of elements in the slice. len int // the number of elements that the slice can // grow to before a new underlying array // is allocated. cap int } 

  
  ये खेत क्या हैं?
  
  
  • data : सूचक को स्लाइस में अंतर्निहित डेटा के लिए
    
  • len : स्लाइस में तत्वों की वर्तमान संख्या
    
  • cap : तत्वों की संख्या को पुनर्वितरित करने से पहले बढ़ सकता है
  
  हुड के तहत धाराएं तय लंबाई की सरणियाँ हैं। जब अधिकतम मूल्य ( cap ) पहुंच जाता है, तो एक डबल मान वाला एक नया सरणी आवंटित किया जाता है, मेमोरी को पुराने स्लाइस से नए में कॉपी किया जाता है, और पुराने एरे को छोड़ दिया जाता है।
  
  मुझे अक्सर इस कोड की तरह कुछ दिखाई देता है जहां एक शून्य सीमा क्षमता वाला स्लाइस आवंटित किया जाता है यदि स्लाइस क्षमता पहले से ज्ञात है:
  
  

   var userIDs []string for _, bar := range rsp.Users { userIDs = append(userIDs, bar.ID) } 

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

   userIDs := make([]string, 0, len(rsp.Users)) for _, bar := range rsp.Users { userIDs = append(userIDs, bar.ID) } 

  
  यहां हमने स्पष्ट रूप से मेक का उपयोग करके स्लाइस के लिए क्षमता आवंटित की है। अब हम अतिरिक्त पुनर्वितरण और नकल के बिना, सुरक्षित रूप से वहां डेटा जोड़ सकते हैं।
  
  यदि आपको पता नहीं है कि कितनी मेमोरी आवंटित करनी है, क्योंकि क्षमता डायनामिक है या बाद में प्रोग्राम में गणना की जाती है, तो प्रोग्राम चलने के बाद स्लाइस साइज़ के अंतिम वितरण को मापें। मैं आमतौर पर 90 वाँ या 99 वाँ प्रतिशत और हार्ड कोड प्रोग्राम में मान लेता हूँ। उन मामलों में जहां सीपीयू आपके लिए रैम से अधिक महंगा है, यह मान जितना आवश्यक है उससे अधिक सेट करें।
  
  टिप नक्शों पर भी लागू होती है: make(map[string]string, len(foo)) पुनर्वितरण से बचने के लिए पर्याप्त मेमोरी आवंटित करेगा।
  
  यह लेख देखें कि स्लाइस वास्तव में कैसे काम करते हैं।
  
  

  बाइट स्लाइस को स्थानांतरित करने के तरीकों का उपयोग करें

  
  पैकेट का उपयोग करते समय, उन तरीकों का उपयोग करें जो बाइट स्लाइस के प्रसारण की अनुमति देते हैं: ये विधियां आमतौर पर वितरण पर अधिक नियंत्रण देती हैं।
  
  एक अच्छा उदाहरण समय की तुलना कर रहा है। समय और समय । पहले एक स्ट्रिंग देता है। हुड के तहत, यह एक नया बाइट स्लाइस चुनता है और time.AppendFormat पर time.AppendFormat कहता है। दूसरा एक बाइट बफर लेता है, एक स्वरूपित समय प्रतिनिधित्व लिखता है, और एक विस्तारित बाइट स्लाइस देता है। यह अक्सर मानक पुस्तकालय में अन्य पैकेजों में पाया जाता है: strconv.AppendFloat या बाइट्स देखें ।NewBuffer ।
  
  इससे उत्पादकता क्यों बढ़ती है? खैर, अब आप उस बाइट स्लाइस को पास कर सकते हैं जो आपको sync.Pool से प्राप्त हुआ था। प्रत्येक बार एक नया बफर आवंटित करने के बजाय। या आप स्लाइस की दोहराई गई प्रतियों की संख्या को कम करने के लिए प्रारंभिक बफर आकार को एक मूल्य पर बढ़ा सकते हैं जो आपके कार्यक्रम के लिए अधिक उपयुक्त है।
  
  

  सारांश

  
  आप इन सभी विधियों को अपने कोड आधार पर लागू कर सकते हैं। समय के साथ, आप गो कार्यक्रमों में प्रदर्शन के बारे में तर्क के लिए एक मानसिक मॉडल का निर्माण करेंगे। इससे उनके डिजाइन में काफी मदद मिलेगी।
  
  लेकिन स्थिति के आधार पर उनका उपयोग करें। ये सलाह हैं, सुसमाचार नहीं। माप और बेंचमार्क के साथ सब कुछ जांचें।
  
  और पता है कब रुकना है। उत्पादकता में वृद्धि एक अच्छा व्यायाम है: कार्य दिलचस्प है, और परिणाम तुरंत दिखाई देते हैं। हालांकि, उत्पादकता बढ़ाने की उपयोगिता स्थिति पर अत्यधिक निर्भर है। यदि आपकी सेवा 10 ms में उत्तर देती है, और नेटवर्क विलंब 90 ms है, तो आपको शायद इन 10 ms को 5 ms तक कम करने का प्रयास नहीं करना चाहिए: आपके पास अभी भी 95 ms हैं। यहां तक ​​कि अगर आप 1 एमएस तक सेवा का अनुकूलन करते हैं, तो भी कुल देरी 91 एमएस होगी। शायद बड़ी मछली खाते हैं।
  
  बुद्धिमानी से अनुकूलन!
  
  

  संदर्भ

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