शुरुआती के लिए मृत कोड हटाना

एक अनुवादक से: दुर्भाग्य से, मैं IE9 बनाम SunSpider के बारे में अनुवाद करने के लिए ब्राउज़र डेवलपर्स से अगली पोस्ट की प्रतीक्षा नहीं करता था, मुझे इसे स्वयं अनुवाद करना था। एक और क्यों? दूसरों ( पहले , दूसरे ) के विपरीत, जो केवल प्रतिबिंब के लिए जानकारी देता था, यह एक भी व्यावहारिक ज्ञान देता है - हर डेवलपर को नए IE9 में अपना कोड लॉन्च करते समय आने वाले नुकसान का वर्णन हो सकता है।

डीन हैचमोविच: हमारे नए जावास्क्रिप्ट इंजन में बदलावों में से एक, कोड नाम चक्र, वास्तविक साइटों के प्रदर्शन को बढ़ाने के लिए मृत कोड का विनाश है। ^{[ १ ]}

कल मैं IE9 में मृत कोड हटाने एल्गोरिथ्म के एक आसान विश्लेषण के बाद एक बग भेजा। उसके बाद, IE9 टीम ने मंच पूर्वावलोकन 7 जारी किया और IE के बारे में अपने ब्लॉग को अपडेट किया ।

मृत कोड को हटाना एक वैध अनुकूलन है, लेकिन बहुत आसानी से सतही कार्यान्वयन अप्रत्याशित व्यवहार को जन्म दे सकता है और त्रुटियों का स्रोत बन सकता है।


IE9 में कार्यान्वित एल्गोरिथ्म की नाजुकता के बारे में, हमारे अध्ययन से पता चला कि केवल निम्नलिखित संचालन को अनुकूलित किया जा सकता है: -, +, ++, <<, + =, - =, और if (>)। उदाहरण के लिए, यदि आप उस परीक्षण में इस तुलना को बदलते हैं:

  अगर (TargetAngle> CurrAngle) { 

पर

  अगर (TargetAngle <= CurrAngle) { 

तब IE9 अब इस कोड को नहीं हटाएगा। यह उत्सुक है कि IE9 के डेवलपर्स ने इस तरह के संसाधन-गहन संचालन को गुणा और विभाजन के रूप में नहीं हटाने का फैसला किया। ऑप्टिमाइज़ेशन के लिए चुने गए ऑपरेशनों का सेट ऐसा लगता है कि सनस्पाइडर में गणित परीक्षणों में इसका इस्तेमाल किया गया है।

तर्क के रूप में, IE9 में मृत कोड हटाने के कार्यान्वयन में पहले से ही कई समस्याएं पाई गई हैं। हमारे डेवलपर्स में से एक, एंड्रियास गैल ने मेरा ध्यान पहली बार आकर्षित किया, जिस पर मैं स्पर्श करूंगा। एक IE ब्लॉग पर डीन ने एक उदाहरण का हवाला दिया:

निम्न उदाहरण में, लूप में कोड लगातार एक ही चर ( सीएस में यह मृत बचत के रूप में जाना जाता है) को ओवरराइट करता है, इसलिए इस कोड को एक कॉल पर सरलीकृत किया जा सकता है।

 फंक्शन फंक (ए, बी) {
    var x;
    var i = 300;
    जबकि (i--) {
       x = a + b;  // डेड स्टोर
    }
 }

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

यह सी # जैसी स्थिर टाइप की भाषाओं के लिए सही हो सकता है, लेकिन दुर्भाग्य से यह जावास्क्रिप्ट के लिए सही नहीं है।

इस फ़ंक्शन को अनुकूलित किया जा सकता है यदि इसे कहा जाता है

  फंक (1,2) 

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

  func (1, {valueOf: function () {अलर्ट ("हाय डीन!"); वापसी 2;}}}; 

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

IE9 प्लेटफ़ॉर्म पूर्वावलोकन # 7 इस उदाहरण को उनके ब्लॉग से सही तरीके से नहीं संभालता (आप कोशिश कर सकते हैं)। यदि किसी फ़ंक्शन को किसी ऑब्जेक्ट के साथ बुलाया जाता है, जिसका मूल्य कार्यान्वयन विधि का अपना कार्यान्वयन है, तो IE9 गलती से इस हैंडलर को नहीं बुलाता है।

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

  फंक (1, [1,2,3,4,5]) 

पहला तर्क एक स्थिर है और सरणी के लिए शाब्दिक काफी सुरक्षित दिखता है। दुर्भाग्य से, यदि प्रोग्राम में इस कॉल से पहले निम्न कोड निष्पादित किया गया था, तो यह विलोपन फिर से सतही हो जाता है:

  Object.prototype.valueOf = function () {अलर्ट ("IE9 तेज है!");  } 

यहाँ हम सभी वस्तुओं के लिए valueOf हैंडलर को फिर से परिभाषित करते हैं, जिसमें शाब्दिक भी शामिल है, और इसलिए + b को जोड़ने से valueff का हमारा कार्यान्वयन कहलाता है। और फिर, IE9 गलती से हमारे हैंडलर के कॉल को याद करता है, और इस मामले को निर्धारित करना पिछले एक की तुलना में और भी कठिन है क्योंकि अब अन्य फाइलों में कोड पहले से ही "अनुकूलन" को प्रभावित कर सकता है।

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

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

जाहिर है, मैं कुछ याद कर सकता था, इसलिए और भी जानकारी कल सुबह आईई टीम से ट्विटर क्यू एंड ए सत्र पर दिखाई देनी चाहिए।

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