कई गो प्रोग्रामर बाइट्स से परिचित हैं। बफ़र । इसका एक लाभ यह है कि यह आपको " छोटे बफर / आकार अनुकूलन " के रूप में उसी तरह से ढेर पर मेमोरी आवंटित करने से बचने की अनुमति देता है:

type Buffer struct { bootstrap [64]byte //        // ...   } 

केवल एक समस्या है। यह अनुकूलन काम नहीं करता है ।

इस लेख के अंत तक, आपको पता चल जाएगा कि यह अनुकूलन क्यों काम नहीं करता है और हम इसके बारे में क्या कर सकते हैं।

जैसा कि इरादा था, "छोटे बफर अनुकूलन"

आइए bytes.Buffer की थोड़ी सरल परिभाषा प्रस्तुत करते हैं। bytes.Buffer :

 const smallBufSize int = 64 type Buffer struct { bootstrap [smallBufSize]byte buf []byte } 

जब हम Buffer पर क्रिया करते हैं, उदाहरण के लिए, Buffer कॉल करें। इसके Buffer.Write , रिकॉर्ड हमेशा buf में बनाया जाता है, हालाँकि, इस रिकॉर्ड से पहले, Buffer.grow(n) प्रत्येक समान विधि के अंदर लॉन्च किया Buffer.grow(n) , जो यह सुनिश्चित करता है कि इस स्लाइस में पर्याप्त जगह हो। अगले n बाइट्स

विकास कुछ इस तरह दिख सकता है:

 func (b *Buffer) grow(n int) { //         bytes.Buffer. l := len(b.buf) //   Buffer need := n + l have := cap(b.buf) - l if have >= need { b.buf = b.buf[:need] return } if need <= smallBufSize { //     , //   . b.buf = b.bootstrap[:] } else { // growFactor -     . //     need  need*2. newBuf := make([]byte, need, growFactor(need)) copy(newBuf, b.buf) b.buf = newBuf } } 

यदि b स्टैक पर आवंटित किया गया है, तो इसके अंदर bootstrap को स्टैक पर आवंटित किया जाता है, जिसका अर्थ है कि स्लाइस b.buf अतिरिक्त आवंटन की आवश्यकता के बिना b अंदर मेमोरी का पुन: उपयोग करेगा।

जब grow पता चलता है कि bootstrap सरणी पहले से ही अपर्याप्त है, तो एक नया, "वास्तविक" स्लाइस बनाया जाएगा, जहां पिछले स्टोरेज ("छोटे बफर" से) तत्वों को कॉपी किया जाएगा। उसके बाद, Buffer.bootstrap अपनी प्रासंगिकता खो देगा। यदि Buffer.Reset , तो cap(b.buf) समान रहेगा और bootstrap सरणी के लिए अधिक आवश्यकता नहीं होगी।

स्मृति ढेर में भाग रही है

आगे यह अपेक्षा की जाती है कि पाठक कम से कम सतही रूप से परिचित हो जो गो में विश्लेषण से बचता है।

निम्नलिखित स्थिति पर विचार करें:

 func f() *Buffer { var b bytes.Buffer // leak.go:11:6: moved to heap: b return &b // leak.go:12:9: &b escapes to heap } 

यहां b को ढेर पर आवंटित किया जाएगा। इसका कारण b को लीक करने वाला सूचक है:

 $ go tool compile -m leak.go leak.go:12:9: &b escapes to heap leak.go:11:6: moved to heap: b 

ऊपर एक स्पष्ट मामला था, लेकिन इसके बारे में क्या:

 func length() int { var b bytes.Buffer b.WriteString("1") return b.Len() } 

यहां हमें केवल 1 बाइट की आवश्यकता है, सब कुछ bootstrap में फिट बैठता है, बफर स्वयं स्थानीय है और फ़ंक्शन से "बच" नहीं जाता है। आप आश्चर्यचकित हो सकते हैं, लेकिन परिणाम समान होगा, ढेर पर आवंटन b ।

सुनिश्चित करने के लिए, आप बेंचमार्क का उपयोग करके इसे देख सकते हैं:

 BenchmarkLength-8 20000000 90.1 ns/op 112 B/op 1 allocs/op 

 package p import ( "bytes" "testing" ) func length() int { var b bytes.Buffer b.WriteString("1") return b.Len() } func BenchmarkLength(b *testing.B) { for i := 0; i < bN; i++ { _ = length() } } 

 package benchmark import "testing" //go:noinline func alloc9() []byte { return make([]byte, 9) } func BenchmarkAlloc9(b *testing.B) { for i := 0; i < bN; i++ { _ = alloc9() } } 

 BenchmarkAlloc9-8 50000000 33.5 ns/op 16 B/op 1 allocs/op 

 fmt.Println(unsafe.Sizeof(bytes.Buffer{})) => 104 

 // class bytes/obj bytes/span objects tail waste max waste // 1 8 8192 1024 0 87.50% // 2 16 8192 512 0 43.75% // 3 32 8192 256 0 46.88% // 4 48 8192 170 32 31.52% // 5 64 8192 128 0 23.44% // 6 80 8192 102 32 19.07% // 7 96 8192 85 32 15.95% // 8 112 8192 73 16 13.56% // ...  

लेकिन ऐसा क्यों हो रहा है?

क्या हो रहा है और क्यों

स्थिति का कुछ विश्लेषण शुरुआत में वर्णित मुद्दे में पाया जा सकता है।
एक साधारण प्रजननकर्ता भी है।

समस्या का स्थान सिर्फ असाइनमेंट b.buf = b.bootstrap[:] । यह कोड बच विश्लेषण का अनुमान b.bootstrap कि b.bootstrap "भाग रहा है", और चूंकि यह एक सरणी है, यह ऑब्जेक्ट के अंदर ही संग्रहीत होता है, जिसका अर्थ है कि सभी b को ढेर पर आवंटित किया जाना चाहिए।

यदि बूटस्ट्रैप एक टुकड़ा था, एक सरणी नहीं, तो ऐसा नहीं होगा, क्योंकि ऑब्जेक्ट से ऑब्जेक्ट पर ही स्लाइस असाइन करने के लिए एडहॉक अनुकूलन है:

 //   ,     , // object      . object.buf1 = object.buf2[a:b] 

उत्तर क्यों यह अनुकूलन सरणियों के लिए काम नहीं करता है पहले से ही ऊपर तैयार किया गया है, लेकिन यहां esc.go # L835-L866 से एक निचोड़ है (संपूर्ण अनुकूलन कोड संदर्भ द्वारा हाइलाइट किया गया है):

 // Note, this optimization does not apply to OSLICEARR, // because it does introduce a new pointer into b that was not already there // (pointer to b itself). After such assignment, if b contents escape, // b escapes as well. If we ignore such OSLICEARR, we will conclude // that b does not escape when b contents do. 

यहां यह ध्यान देने योग्य है कि सूचक विश्लेषक के लिए "लीक" के कई स्तर हैं, उनमें से मुख्य हैं:

1. ऑब्जेक्ट ही बच जाता है (b es एस्केप)। इस मामले में, ऑब्जेक्ट को हीप पर आवंटित करने की आवश्यकता है।
2. ऑब्जेक्ट के तत्व (बी सामग्री बच) से बच जाते हैं। इस स्थिति में, ऑब्जेक्ट में पॉइंटर्स को भागने से माना जाता है।

ऐरे के साथ मामला इस लिहाज से खास है कि अगर एरे लीक होता है, तो उसमें मौजूद ऑब्जेक्ट भी लीक होना चाहिए।

विश्लेषण का विश्लेषण इस बात पर निर्णय करता है कि क्या स्टैक पर किसी वस्तु को रखना संभव है या नहीं, केवल उस जानकारी पर निर्भर है जो विश्लेषण किए गए फ़ंक्शन के शरीर में उपलब्ध है। Buffer.grow विधि सूचक द्वारा b लेती है, इसलिए इसे लगाने के लिए एक उपयुक्त स्थान की गणना करने की आवश्यकता है। चूंकि एक सरणी के मामले में हम "b escape" को "b contents escape" "b escape" से अलग नहीं कर सकते "b contents escape" , इसलिए हमें अधिक निराशावादी होना होगा और इस निष्कर्ष पर आना होगा कि b स्टैक पर जगह के लिए सुरक्षित नहीं है।

इसके विपरीत मान लें कि self-assignment पैटर्न सरणियों के लिए उसी तरह हल करता है जैसे कि यह स्लाइस के लिए करता है:

 package example var sink interface{} type bad struct { array [10]byte slice []byte } func (b *bad) bug() { b.slice = b.array[:] // ignoring self-assignment to b.slice sink = b.array // b.array escapes to heap // b does not escape } 

इस स्थिति में स्टैक पर b लगाने का निर्णय आपदा को जन्म देगा: जिस फ़ंक्शन के अंदर b बनाया गया था, उसे बाहर करने के बाद, जिस मेमोरी को sink संदर्भित करेगा, वह कचरे से ज्यादा कुछ नहीं होगा।

एरियर पॉइंटर्स

कल्पना कीजिए कि हमारे Buffer को थोड़ा अलग घोषित किया गया था:

 const smallBufSize int = 64 type Buffer struct { - bootstrap [smallBufSize]byte + bootstrap *[smallBufSize]byte buf []byte } 

एक नियमित सरणी के विपरीत, सरणी के लिए एक सूचक Buffer अंदर सभी तत्वों को संग्रहीत नहीं करेगा। इसका मतलब यह है कि अगर bootstrap आवंटन ढेर पर होता है तो ढेर पर Buffer आवंटन नहीं होता है। चूंकि एस्केप विश्लेषण संभव होने पर स्टैक पर पॉइंटर फ़ील्ड आवंटित कर सकते हैं, हम मान सकते हैं कि ऐसी Buffer परिभाषा अधिक सफल है।

लेकिन यह सिद्धांत में है। व्यवहार में, एक सरणी के लिए एक संकेतक में बहुत अधिक प्रसंस्करण नहीं होता है और एक नियमित श्रेणी से एक स्लाइस के रूप में एक ही श्रेणी में आता है, जो पूरी तरह से सही नहीं है। CL133375: cmd / compile / आंतरिक / gc: एस्सेंगो में एरे स्लाइस सेल्फ-असाइन को संभालना इस स्थिति को ठीक करना है।

मान लीजिए कि इस परिवर्तन को गो संकलक में स्वीकार कर लिया गया है।

शून्य मान हमने खो दिया

दुर्भाग्य से, [64]byte से *[64]byte में संक्रमण की समस्या है: अब हम bootstrap उपयोग बिना स्पष्ट रूप से शुरू किए बिना नहीं कर सकते, Buffer का एक शून्य मान उपयोगी होना बंद कर देता है, हमें एक निर्माता की आवश्यकता है।

 func NewBuffer() Buffer { return Buffer{bootstrap: new(*[smallBufSize]byte)} } 

हम Buffer लौटाते हैं, न कि *Buffer , NewBuffer के विश्लेषण के साथ समस्याओं से बचने के लिए (यह गो में बहुत रूढ़िवादी है), और इस तथ्य को ध्यान में रखते हुए कि NewBuffer हमेशा कॉल के स्थान पर बनाया जाता है, कोई अनावश्यक प्रतिलिपि नहीं होगी।

एस्केप कॉल के स्थान पर NewBuffer बॉडी को एम्बेड करने के बाद, विश्लेषण यह साबित करने की कोशिश कर सकता है कि new(*[smallBufSize]byte) फ़ंक्शन के फ्रेम के जीवनकाल से अधिक नहीं है जिसमें इसे कहा जाता है। यदि ऐसा है, तो आवंटन स्टैक पर होगा।

इंटेल बाइटबुफ

ऊपर वर्णित अनुकूलन Intel-go / bytebuf पैकेज में लागू किया गया है।

यह लाइब्रेरी bytebuf.Buffer प्रकार का निर्यात करती है, जो 99.9% bytes.Buffer डुप्लिकेट bytes.Buffer । bytes.Buffer । सभी परिवर्तनों को एक निर्माता ( bytebuf.New ) और एक सूचक के बजाय एक नियमित रूप से एक सरणी की शुरूआत करने के लिए कम किया जाता है:

 type Buffer struct { buf []byte // contents are the bytes buf[off : len(buf)] off int // read at &buf[off], write at &buf[len(buf)] - bootstrap [64]byte // helps small buffers avoid allocation. + bootstrap *[64]byte // helps small buffers avoid allocation. lastRead readOp // last read operation (for Unread*). } 

यहाँ bytes.Buffer साथ एक प्रदर्शन तुलना है। bytes.Buffer :

 name old time/op new time/op delta String/empty-8 138ns ±13% 24ns ± 0% -82.94% (p=0.000 n=10+8) String/5-8 186ns ±11% 60ns ± 1% -67.82% (p=0.000 n=10+10) String/64-8 225ns ±10% 108ns ± 6% -52.26% (p=0.000 n=10+10) String/128-8 474ns ±17% 338ns ±13% -28.57% (p=0.000 n=10+10) String/1024-8 889ns ± 0% 740ns ± 1% -16.78% (p=0.000 n=9+10) name old alloc/op new alloc/op delta String/empty-8 112B ± 0% 0B -100.00% (p=0.000 n=10+10) String/5-8 117B ± 0% 5B ± 0% -95.73% (p=0.000 n=10+10) String/64-8 176B ± 0% 64B ± 0% -63.64% (p=0.000 n=10+10) String/128-8 368B ± 0% 256B ± 0% -30.43% (p=0.000 n=10+10) String/1024-8 2.16kB ± 0% 2.05kB ± 0% -5.19% (p=0.000 n=10+10) name old allocs/op new allocs/op delta String/empty-8 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10) String/5-8 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=10+10) String/64-8 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=10+10) String/128-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.000 n=10+10) String/1024-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.000 n=10+10) 

अन्य सभी जानकारी README में उपलब्ध है।

शून्य मान का उपयोग करने में असमर्थता और निर्माण कार्य New करने के लिए बाध्य होने के कारण, इस अनुकूलन को bytes.Buffer लिए लागू करना संभव नहीं है।

क्या यह तेजी से bytes.Buffer बनाने का एकमात्र तरीका है। bytes.Buffer ? जवाब है नहीं। लेकिन यह निश्चित रूप से एक ऐसी विधि है जिसे कार्यान्वयन में न्यूनतम बदलाव की आवश्यकता होती है।

एस्केप एनालिसिस प्लान

अपने वर्तमान स्वरूप में, गो में बच विश्लेषण बहुत कमजोर है। सूचक मूल्यों के साथ लगभग कोई भी ऑपरेशन ढेर पर आवंटन की ओर जाता है, भले ही यह एक उचित निर्णय न हो।

मैं ज्यादातर समय यह निर्देशित करने की कोशिश करूंगा कि मैं इन समस्याओं को हल करने के लिए गोलंग / गो परियोजना को समर्पित करता हूं , इसलिए आगामी रिलीज (1.12) में कुछ सुधार संभव हैं।

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