2010-07-21 19 views
44

एक .NET प्रोग्राम पहले एमएसआईएल कोड में संकलित किया गया है। जब इसे निष्पादित किया जाता है, तो जेआईटी कंपाइलर इसे मूल मशीन कोड में संकलित करेगा।.NET JIT- संकलित कोड कैश किया गया है?

मैं सोच रहा हूँ:

जहां इन JIT संकलित मशीन कोड संग्रहीत किया जाता है? क्या यह केवल प्रक्रिया के पता स्थान में संग्रहीत है? लेकिन चूंकि कार्यक्रम की दूसरी स्टार्टअप पहली बार बहुत तेज है, मुझे लगता है कि निष्पादन समाप्त होने के बाद भी यह देशी कोड डिस्क पर कहीं भी संग्रहीत किया जाना चाहिए। पर कहा?

उत्तर

69

मेमोरी विश्वास। यह कैश किया जा सकता है, यह ngen.exe का काम है। यह असेंबली का .ni.dll संस्करण उत्पन्न करता है, जिसमें मशीन कोड होता है और जीएसी में संग्रहीत होता है। जेआईटी चरण को छोड़कर स्वचालित रूप से लोड हो जाता है।

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

डिस्क धीमी हैं। एक एसएसडी एक स्पष्ट फिक्स है।

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

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

आप इस चाल का भी उपयोग कर सकते हैं, लेकिन कृपया इसे जिम्मेदारी से उपयोग करें।

+17

विस्टा और विंडोज 7 में यह डीएलएल कैशिंग चाल है, इसलिए आपको अब "ऐप त्वरक" बनाने की आवश्यकता नहीं है। सुपरफैच रिकॉर्ड करता है कि आप कौन से अनुप्रयोगों का सबसे अधिक उपयोग करते हैं और बूट के बाद उन फ़ाइलों को पढ़ेंगे। यह एक त्वरक ऐप से बेहतर है क्योंकि यह वर्तमान स्मृति उपयोग और वास्तविक अनुप्रयोग उपयोग पर ध्यान देता है। –

+1

@ हंस: आपने कहा "यह असेंबली का .ni.dll संस्करण उत्पन्न करता है, जिसमें मशीन कोड होता है और जीएसी में संग्रहीत होता है"। मुझे कुछ संदेह है .. जीएसी केवल सार्वजनिक असेंबली भंडार करने के लिए है, है ना? क्या यह 'exe' की' मूल छवि 'संग्रहीत करता है जिसे मैं चला रहा हूं? – Sreekumar

+0

हां, यही जवाब है। यह दृश्य से छिपा हुआ है लेकिन आप कमांड प्रॉम्प्ट शुरू करके इसे देख सकते हैं। जीएसी में निर्देशिकाओं को सूचीबद्ध करने के लिए 'dir c: \ windows \ assembly' टाइप करें। –

2

संक्षेप में, आईएल कार्यक्रम के प्रत्येक आमंत्रण के लिए जेआईटी-संकलित है और प्रक्रिया पता स्थान के कोड पृष्ठों में बनाए रखा जाता है। .NET निष्पादन मॉडल के महान कवरेज के लिए Richter का अध्याय 1 देखें।

1

मुझे विश्वास है कि जेआईटी संकलित कोड कभी भी संग्रहीत नहीं किया जाता है या स्मृति से बाहर नहीं बदला जाता है। एक असेंबली के दूसरे निष्पादन पर आपको जो प्रदर्शन बढ़ावा मिलता है वह निर्भर रूप से स्मृति या डिस्क कैश में निर्भर असेंबली के कारण होता है।

+0

केवल कर्नेल ड्राइवर कोड को स्वैप आउट होने से रोक सकते हैं। जेआईटी संकलित कोड को एप्लिकेशन मेमोरी में किसी अन्य पेज की तरह ही बाहर किया जा सकता है। –

7

जेआईटी संकलित मशीन कोड मेमोरी प्रति-विधि में कैश किया जाता है, प्रत्येक बार जब पहली बार एक विधि निष्पादित की जाती है। मुझे नहीं लगता कि यह कभी डिस्क पर कैश किया गया है।

आप पाते हैं कि प्रक्रिया दूसरी बार लोड करने के लिए तेज़ है क्योंकि विंडोज़ पहली प्रक्रिया में आपकी प्रक्रिया (डीएलएस, संसाधन इत्यादि) द्वारा उपयोग की जाने वाली फ़ाइलों को कैश (मेमोरी में) कैश करता है। दूसरे भाग पर डिस्क पर जाने की कोई आवश्यकता नहीं है, जहां यह पहले रन पर किया जा सकता है।

आप अपने वास्तुकला के लिए मशीन कोड को पूर्व-संकलित करने के लिए running NGen.exe द्वारा इसकी पुष्टि कर सकते हैं और पहले और दूसरे रनों के प्रदर्शन की तुलना कर सकते हैं। मेरी शर्त यह है कि ओएस में कैशिंग के कारण दूसरा रन अभी भी तेज होगा।

+0

क्या आप जानते हैं कि विंडोज़ इन प्रक्रियाओं (डीएलएस, संसाधन इत्यादि) द्वारा उपयोग की जाने वाली फाइलों को कैश कर रही है? – Sreekumar

+0

@ श्रीकुमार: रैम में, इन दिनों लगभग हर दूसरे ओएस के समान ही। – SamB

11

जैसा कि अन्य ने इंगित किया है, कोड आपके मामले में प्रति प्रक्रिया आधार पर JIT'd है, और कैश नहीं किया गया है - आप दूसरे लोड पर देख रहे स्पीड-अप ओएस डिस्क कैशिंग (यानी इन-मेमोरी) है असेंबली

हालांकि, फ्रेमवर्क के डेस्कटॉप \ सर्वर संस्करण में कोई कैशिंग नहीं है (ओएस डिस्क कैशिंग के अलावा), फ्रेमवर्क के किसी अन्य संस्करण में JIT'd मशीन कोड की कैशिंग है।

रुचि कॉम्पैक्ट फ्रेमवर्क (विंडोज फोन 7 रिलेज़ के लिए एनईटीसीएफ) में क्या हो रहा है। हालिया प्रगति उन प्रक्रियाओं के बीच कुछ जेआईटीएड फ्रेमवर्क कोड साझा करना देखें जहां जेआईटीएड कोड वास्तव में कैश किया गया है। यह मुख्य रूप से मोबाइल फोन जैसे बाध्य उपकरणों में बेहतर प्रदर्शन (लोड समय और मेमोरी उपयोग) के लिए किया गया है।

तो सवाल के जवाब में सीएलआर के डेस्कटॉप \ सर्वर संस्करण में JIT'd कोड का कोई प्रत्यक्ष ढांचा कैशिंग नहीं है, लेकिन कॉम्पैक्ट फ्रेमवर्क यानी एनईटीसीएफ के नवीनतम संस्करण में होगा।

संदर्भ: हम शेयरिंग में

http://blogs.msdn.com/b/abhinaba/archive/2010/04/28/we-believe-in-sharing.aspx

1

हां, NGEN.EXE जीएसी में एक .NET निष्पादन योग्य के जेआईटी संकलित संस्करण को रखेगा, भले ही एमएसआईएल संस्करण वहां नहीं है। मैंने कोशिश की है, लेकिन इसका कोई फायदा नहीं हुआ। मेरा मानना ​​है कि जब तक मूल एमएसआईएल संस्करण जीएसी में भी नहीं है और वहां से लोड किया जाएगा, जीएसी में जेआईटी संस्करण का उपयोग नहीं किया जाएगा। मुझे यह भी विश्वास है कि ऑन-द-फ्लाई जेआईटी संकलन ( एनजीईएन) कभी कैश नहीं किया जाता है; वे केवल मेमोरी प्रक्रिया पर कब्जा करते हैं।

मुझे यह मानना ​​है कि यह एमएस डॉक्टर और विभिन्न प्रयोगों से पढ़ने से है। मैं का स्वागत करता हूं जो "जो जानते हैं" से मेरे दावे की पुष्टि या खंडन।

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