2012-12-13 12 views
13

मूलतः http://jsperf.com/in-vs-member-object-accessजावास्क्रिप्ट का "इन" ऑपरेटर निरंतर कठोर सदस्य तुलना की तुलना में धीमी गति से क्यों धीमा है?

देखें, क्यों if ('bar' in foo) {} जाँच कर रहा है if (foo.bar !== undefined) {} की तुलना में काफी धीमी?

+0

[इसी तरह के परिणामों के साथ समान बेंचमार्क] (http://jsperf.com/in-versus-bracket-versus-dot) – bfavaretto

+0

मेरे परिणाम समान थे। हालांकि, "इन" के बजाय अस्तित्व की जांच करने के लिए अन्य अच्छे उम्मीदवार हैं, http://jsperf.com/dictionary-contains-key – styfle

उत्तर

5

foo.bar !== undefined यह देखने के लिए कि वे मेल खाते हैं या नहीं, केवल 2 मानों की जांच करता है।

जबकि 'bar' in foofoo के गुणों के माध्यम से bar में यह देखने के लिए कुछ तंत्र का उपयोग करना होगा।

यहाँ ऐक्मा स्क्रिप्ट

से एक दिलचस्प पढ़ें है ऑपरेटर में

उत्पादन RelationalExpression:
1. मूल्यांकन RelationalExpression: ShiftExpression में RelationalExpression इस प्रकार मूल्यांकन किया जाता है।
2. GetValue (परिणाम (1) पर कॉल करें)।
3. ShiftExpression का मूल्यांकन करें।
4. GetValue (परिणाम (3) पर कॉल करें)।
5. यदि परिणाम (4) कोई ऑब्जेक्ट नहीं है, तो TypeError अपवाद फेंक दें।
6. कॉल टूस्ट्रिंग (परिणाम (2))।
7. पैरामीटर परिणाम (6) के साथ परिणाम (4) की [[HasProperty]] विधि को कॉल करें।
8. वापसी परिणाम (7)।

सख्त करता है-नहीं-बराबर ऑपरेटर (==!)

उत्पादन EqualityExpression: EqualityExpression == RelationalExpression इस प्रकार मूल्यांकन किया जाता है:
1. मूल्यांकन EqualityExpression।
2. GetValue (परिणाम (1) पर कॉल करें)।
3. RelationalExpression का मूल्यांकन करें।
4. GetValue (परिणाम (3) पर कॉल करें)।
5. तुलना परिणाम (4) === परिणाम (2) करें। (नीचे देखें।)
6. यदि परिणाम (5) सत्य है, तो झूठी वापसी करें। अन्यथा, सच वापसी करें।

+2

इस जानकारी को सीधे आपके उत्तर में इनलाइन करने के लिए धन्यवाद। मैंने पहले से ही एक जवाब स्वीकार कर लिया है, लेकिन मैं वास्तव में इसे यहां रखने के लिए अपना समय लेने की सराहना करता हूं। मुझे यकीन है कि दूसरों को यह अमूल्य मिल जाएगा। –

+0

यह उत्तर गलत है; यह निर्धारित करना कि 'foo' में' bar' प्रॉपर्टी है या नहीं, दोनों परिचालनों में पहला कदम है। Foo' में 'bar' का कोई कारण नहीं है 'foo.bar! == अपरिभाषित' के रूप में नहीं हो सकता है। कारण 'धीमा' धीमा है कि इसे अधिक अनुकूलित नहीं किया गया है। –

+0

@JasonOrendorff मुझे विश्वास नहीं है कि 'f' में 'bar' 'foo.bar! == अपरिभाषित 'के समान है, या तो अर्थात् या कार्यान्वयन के मामले में। निम्नलिखित कोड 'x = {} पर विचार करें; x.a = अपरिभाषित; '। इन दो बयानों को निष्पादित करने के बाद, आप '(' ए 'में x) == (x.a! == अपरिभाषित)' के परिणाम की अपेक्षा करेंगे? मैं तर्क दूंगा कि वर्तमान व्यवहार, 'झूठा' क्या होता है, जबकि आप बहस करते हैं कि परिणाम 'सत्य' होना चाहिए। –

4

आप सही हैं। से धीमे होने के लिए "bar" in foo के लिए इसका कोई मतलब नहीं है।

एकमात्र कारण in इतना तेज़ नहीं है कि इसे जेआईटी इंजीनियरों से ज्यादा ध्यान नहीं मिला है जितना अधिक आम foo.bar वाक्यविन्यास।

विशेष रूप से अपने jsperf परीक्षण, जहां संपत्ति करता ही foo पर सीधा संपत्ति (नहीं एक प्रोटोटाइप) के रूप में मौजूद में मामले में, यह कारण है कि 'bar' in foo किसी भी foo.bar !== undefined की तुलना में धीमी नहीं होना चाहिए खड़ा है। यदि कुछ भी हो, तो यह तेज़ होना चाहिए। दोनों के बीच मुख्य अंतर यह है कि in का उत्तर संपत्ति के मूल्य की जांच किए बिना भी दिया जा सकता है!

foo.bar मामले में, मुझे उम्मीद है कि वी 8 इंजन और स्पाइडरमोन्की इंजन दोनों ही यह पता लगाएंगे कि कोड कुछ भी उपयोगी नहीं कर रहा है (यानी, इसका कोई प्रभावशाली प्रभाव नहीं है) और इसे पूरी तरह से अनुकूलित करें।बेंचमार्क किसी भी वास्तविक काम को माप नहीं रहा है।

स्पष्ट रूप से इंजन "bar" in foo को अनुकूलित करने के लिए पर्याप्त स्मार्ट नहीं हैं, लेकिन यह केवल समय की बात है। और प्राथमिकताओं।

संबंधित मुद्दे

 संबंधित मुद्दे