Juicer कक्षा में निम्न विधि पर विचार करें:,प्रयास के लायक स्मॉलटॉक बाइटकोड अनुकूलन हैं?
25 self ; 1
26 pushTemp: 0 ; 2
27 send: gather:
28 popIntoTemp: 1 ; 3 *
29 self ; 4 *
30 pushTemp: 1 ; 5 *
31 send: extractJuiceFrom:
32 storeIntoTemp: 2 ; 6 <-
33 send: withoutSeeds
34 returnTop
अगला पर विचार 28:
Juicer >> juiceOf: aString
| fruit juice |
fruit := self gather: aString.
juice := self extractJuiceFrom: fruit.
^juice withoutSeeds
यह अब निम्नलिखित bytecodes
25 self ; 1
26 pushTemp: 0 ; 2
27 send: gather:
28 popIntoTemp: 1 ; 3
29 self ; 4
30 pushTemp: 1 ; 5
31 send: extractJuiceFrom:
32 popIntoTemp: 2 ; 6 <-
33 pushTemp: 2 ; 7 <-
34 send: withoutSeeds
35 returnTop
उत्पन्न करता है ध्यान दें कि 32 और 33 को रद्द 2 9 और 30. gather के परिणाम से नीचे self डालें। एक ही ढेर विन्यास पहले संदेश भेजने से पहले self धकेलने के द्वारा प्राप्त किया जा सकता था किया गया है:
25 self ; 1 <-
26 self ; 2
27 pushTemp: 0 ; 3
28 send: gather:
29 popIntoTemp: 1 ; 4 <-
30 pushTemp: 1 ; 5 <-
31 send: extractJuiceFrom:
32 storeIntoTemp: 2 ; 6
33 send: withoutSeeds
34 returnTop
अब 29 और 30
25 self ; 1
26 self ; 2
27 pushTemp: 0 ; 3
28 send: gather:
29 storeIntoTemp: 1 ; 4 <-
30 send: extractJuiceFrom:
31 storeIntoTemp: 2 ; 5
32 send: withoutSeeds
33 returnTop
रद्द temporaries 1 और 2 में लिखा जाता है न कि उन्हें पढ़ने।
25 self ; 1
26 self ; 2
27 pushTemp: 0 ; 3
28 send: gather:
29 send: extractJuiceFrom:
30 send: withoutSeeds
31 returnTop
इस अंतिम संस्करण है, जो 4 से 7 ढेर आपरेशन बचाता है, कम अर्थपूर्ण और स्पष्ट स्रोत से मेल खाती है:
Juicer >> juiceOf: aString
^(self extractJuiceFrom: (self gather: aString)) withoutSeeds
तो, जब डिबगिंग को छोड़कर, वे करने के लिए अग्रणी को छोड़ दिया जा सकता है ध्यान दें कि अन्य संभावित अनुकूलन भी हैं जो फारो (मैंने स्क्वाक की जांच नहीं की है) लागू नहीं होती है (उदाहरण के लिए, जंप चेनिंग।) ये अनुकूलन छोटे कंप्यूटेशंस प्रोग्रामर को अतिरिक्त गणनाओं की लागत का भुगतान किए बिना अपने इरादों को बेहतर व्यक्त करने के लिए प्रोत्साहित करेंगे।
मेरा सवाल यह है कि क्या ये सुधार भ्रम हैं या नहीं। कंक्रीटली, फ़ारो/स्क्वाक से अनुपस्थित बाइटकोड अनुकूलन हैं क्योंकि उन्हें कम प्रासंगिकता के लिए जाना जाता है, या उन्हें फायदेमंद माना जाता है लेकिन अभी तक उन्हें संबोधित नहीं किया गया है?
संपादित
एक रजिस्टर + ढेर वास्तुकला का उपयोग करने का एक दिलचस्प लाभ [cf. A Smalltalk Virtual Machine Architectural Model एलन विर्फ़्स-ब्रॉक और पैट कैडिल द्वारा] यह है कि रजिस्टरों द्वारा प्रदान की गई अतिरिक्त जगह ऑप्टिमाइज़ेशन के लिए बाइटकोड्स में हेरफेर करना आसान बनाता है। बेशक, भले ही इन प्रकार के अनुकूलन विधि इनलाइनिंग या पॉलिमॉर्फिक इनलाइन कैश के रूप में प्रासंगिक नहीं हैं, जैसा कि नीचे दिए गए उत्तर में बताया गया है, उन्हें विशेष रूप से जब जेआईटी कंपाइलर द्वारा लागू अन्य लोगों के साथ संयुक्त किया जाना चाहिए, तो उन्हें अवहेलना नहीं किया जाना चाहिए। विश्लेषण करने के लिए एक और दिलचस्प विषय यह है कि विनाशकारी ऑप्टिमाइज़ेशन (यानी, जिसे डीबगर का समर्थन करने के लिए डी-ऑप्टिमाइज़ेशन की आवश्यकता होती है) वास्तव में आवश्यक है या पर्याप्त प्रदर्शन लाभ गैर-विनाशकारी तकनीकों द्वारा प्राप्त किया जा सकता है।
मैं इस बात से सहमत हूं कि लाभ अनुकूलन को लागू करने के लिए आवश्यक जटिलता को उचित नहीं ठहरा सकता है। ध्यान दें कि डिबगिंग करते समय भी आप स्टोर्स को temps में रख सकते हैं और व्याख्या करते समय उन्हें छोड़ सकते हैं। आप जिटर के बारे में भी एक अच्छा मुद्दा बनाते हैं। हालांकि, जिटर अन्य अनुकूलन स्वीकार करता है और उन सभी को एक ही स्थान पर लागू करने में थोड़ा असुविधाजनक हो सकता है। जवाब देने के लिए बहुत धन्यवाद। –
@LeandroCaniglia लाभ तब भी दिलचस्प होता है जब स्टैक ऑप्स की तुलना में अधिक महंगे होते हैं - मेरे संपादन –
@LeandroCaniglia को डिबगिंग के बारे में देखें, कल्पना करें कि मैं अनुकूलित विधि निष्पादित करता हूं, लेकिन एक अनचाहे अपवाद हुआ क्योंकि #extractJuiceFrom: भेज रहा है # फल पर दबाएं और प्रेस समझा नहीं जाता है। Temps फल और रस के मूल्य को प्रदर्शित करने के लिए यह स्पष्ट नहीं है, और क्या होता है यदि मैं किसी अन्य वस्तु के साथ temps असाइन करता हूं, आदि ... –