تو قسمتهای قبلی (1 و 2 و 3 و 4 و 5) بحث های نسبتا عمیقی راجع به بخشهای مهم CLR ارائه شد. تو این قسمت درباره یکی از ابزارهای مرتبط با فعالیت CLR، یعنی NGen.exe بحث میشه. این ابزار که به اون Native Generator یا Native Image Generator هم گفته میشه، برای تهیه کد native استفاده میشه.
ابزار NGen.exe به همراه دات نت فریمورک تو همون مسیر نصب نسخه مربوطه از دات نت (مثلا <C:\Windows\Microsoft.NET\Framework\<Version) نصب میشه. از این ابزار معمولا برای کامپایل کد IL اسمبلی ها به کد Native در زمان نصب (install) اپلیکیشن ها استفاده میشه و ازاونجاکه با استفاده از این ابزار، کدها در زمان نصب کامپایل میشن، دیگه CLR در زمان اجرا از JIT کامپایلر برای کامپایل کد IL استفاده نمیکنه، که اینکار باعث افزایش کارایی و سرعت اجرای برنامه میشه.
البته استفاده از NGen.exe به همین سادگی ها نیست و معایب و مزایای خاص خودش رو داره که تو این مطلب به اون پرداخته شده.
نکات مثبت
ابزار NGen.exe در دو مورد زیر کاربرد موثری داره:
- کاهش زمان آغاز به کار اپلیکیشن: درصورت اجرای NGen.exe، چون قبل از اجرای برنامه کدهای native تولید شدن، بنابراین بدلیل عدم نیاز به اجرای کامپایلر JIT و سایر فرایندهای درگیر، سرعت بارگذاری اولیه برنامه زیاد میشه.
- کاهش working set اپلیکیشن: ازاونجاکه با اجرای NGen.exe کد native تولیدشده به صورت مجزا تو یه فایل دیگه ذخیره میشه، بنابراین در زمان اجرا محتوای این فایل جدید به صورت فقط خواندنی تو حافظه بارگذاری شده و درنتیجه حافظه اضافی ای که در صورت بارگذاری کد خام IL و کامپایل اون در زمان اجرا مصرف میشه رو نیاز نداره. بدین ترتیب مقدار حافظه مصرفی توسط اپلیکیشن و درنتیجه woking set اون کاهش پیدا میکنه. برای اطلاعات بیشتر راجع به Working Set یه پراسس تو ویندوز به اینجا رجوع بشه.
وقتیکه یه برنامه ستاپ (setup یا نصب کننده یا installer) ابزار NGen.exe رو یه اپلیکیشن و یا یه اسمبلی خاص اجرا میکنه، تمامی کدهای IL موجود به کد native کامپیوتر مقصد کامپایل میشن. درنتیجه یه فایل اسمبلی جدید حاوی این کدهای native حاصله تولید میشه. این فایل تو یه مسیر مشخص ذخیره میشه. این مسیر خاص چیزی شبیه مسیر زیره:
همونوطور که مشاهده میشه، این مسیر شامل نسخه CLR (یا دات نت فریمورک) و همچنین پسوندی مطابق با نسخه سیستم عامل (32 یا 64 بیتی) هست.
حالا، هر وقت CLR فایل یه اسمبلی رو بارگذاری میکنه، اول چک میکنه که آیا فایل حاوی کدهای native برای این اسمبلی قبلا توسط NGen.exe تو این مسیر خاص تولید شده یا نه. اگه فایلی پیدا نشه، کامپایل کدهای IL اسمبلی طبق روال عادی توسط کامپایلر JIT انجام میشه. اما اگه چنین فایلی پیدا بشه، CLR از این کدهای native استفاده میکنه و دیگه عملیات کامپایل زمان اجرا رو انجام نمیده.
نکات منفی
خوب، با این توصیفات به نظر میرسه که استفاده از ابزار NGen.exe فواید زیادی داره و تمام برنامه ها باید از این ابزار به هر صورت استفاده کنن. اما چرا تو دنیای دات نت این ابزار چندان معروف و محبوب نیست؟ چون استفاده از این ابزار دردسرهایی هم داره و دلایلی که برای این عدم محبوبیت میشه اشاره کرد به شرح زیرن:
- نیاز به اسمبلی های اصلی برنامه به همراه نسخه های NGen شده: همونوطور که در بالا هم اشاره شد، برای استفاده از اسمبلی هایی که توسط این ابزار تولید شدن، نیازه تا اول اسمبلی های اصلی حاوی کدهای خام IL توسط CLR بازگذاری بشه. در زمان اجرا CLR نیاز به متادیتای اسمبلی ها داره که این مورد مهم باعث میشه تا اسمبلی های اصلی برنامه همیشه در زمان اجرا موردنیاز باشند. این فرایند کار توزیع و انتشار برنامه ها رو کمی مشکل میکنه.
- عدم وجود حفاظت از کدهای خام IL: با اینکه در نگاه اول تصور میشه که در صورت استفاده از این ابزار میشه از کدهای حساس برنامه محافظت کرد، اما با توجه به توضیحات قبلی، چون لازمه تا اسمبلی های حاوی کدهای خام IL هم در زمان اجرا حضور داشته باشن، عملا این حفاظت موردنیاز بدست نمیاد.
- احتمال عدم هماهنگی فایلهای NGenشده: وقتیکه CLR یه فایل NGenشده رو بارگذاری میکنه، اول یه سری مشخصات معین کد کامپایل شده رو با محیط اجرای جاری چک میکنه. اگه حتی یکی از این مشخصات هماهنگی نداشته باشه، CLR از استفاده از کدهای NGenشده صرفنظر میکنه و میره سراغ کامپایلر JIT. برخی از این مشخصات اشاره شده عبارتنداز:
* نسخه CLR: این مقدار با بروزرسانی های مختلف دات نت فریمورک تغییر میکنه.
* مشخصات پردازنده: که با تغییر اون تغییر میکنه.
* نسخه سیستم عامل: که با بروزرسانی هایی که انجام میشه تغییر میکنه.
* شناسه MVID (یا Module Version ID) اسمبلی: با کامپایل دوباره اسمبلی تغییر میکنه.
* شناسه نسخه های ریفرنسها: این مقدار نیز با کامپایل دوباره خود ریفرنسها تغییر میکنه.
* امنیت: این مشخصه هم با تغییر تنظیمات دسترسی به کد (شامل انواع دسترسی های امنیتی و فلگهای مربوطه) تغییر میکنه.
- احتمال کارایی کمتر در زمان اجرا: ابزار NGen.exe در زمان کامپایل فرضیات و اطلاعات کمتری از کامپایلر JIT در زمان اجرا درباره محیط اجرا داره که باعث میشه کدهایی با کارایی کمتری تولید کنه. مثلا NGen.exe بهینه سازی کد رو بر اساس دستورالعملهای خاص یه پردازنده یا معماری انجام نمیده، و یا بدلیل اینکه نمیتونه از آدرس واقعی فیلدهای استاتیک یه نوع در زمان کامپایل مطلع باشه، بنابراین از فرایندها و دستورالعملهایی برای جایگزینی این کمبود و اجرای غیرمستقیم فرایندهای مربوطه استفاده میکنه. این ابزار بدلیل اینکه مثل کامپایلر JIT دقیقا از مسیر و الگوی اجرای کدها آگاه نیست، مثلا فراخوانی کانستراکتورهای یه کلاس رو همه جا پیاده میکنه بدون اینکه بدونه کانستراکتوری قبلا فراخوانی شده یا نه.
مسائلی از این دست باعث شده که کدهایی که در اثر کامپایل NGen.exe تولید شدن، تو برخی موارد عملا کارایی کمتری نسبت به کدهای کامپایلر JIT داشته باشن. برخی از این مسائل مشکلات ذاتی نحوه کامپایل NGen هست و برخی هم محدودیتهای پیاده سازی این ابزاره. تو تستها نشون داده شده که بعضی از کدهای NGenشده حدود 5 درصد کندتر از کدهای JIT کامپایل شده اجرا میشن.
بنابراین اگه هدف استفاده از NGen.exe افزایش کارایی اپلیکیشن هست، بنابراین قبل از توزیع و انتشار نرم افزار باید یه سری آزمونهای کارایی اجرا بشه تا از افزایش کارایی اطمینان حاصل بشه. مثلا تو برخی از برنامه کاهش Working Set اهمیت زیادی داره و اگه تستها نتایج خوبی داشته باشه استفاده از این ابزار میتونه مقرون به صرفه باشه.
نتیجه گیری
پس استفاده از ابزار NGen.exe باید با احتیاط زیادی انجام بشه. در اپلیکیشنهای سروری استفاده از این ابزار ارزش افزوده خاصی به همراه نداره، چون معمولا با ورود کاربر اول، بیشتر فرایند کامپایل JIT انجام میشه و بقیه کاربرها از کدهای کامپایل شده موجود استفاده میکنن. درضمن چون تو بیشتر اپلیکیشنهای سروری تنها یه نسخه از برنامه اجرا میشه، بنابراین مشکلات مربوط به Working Set هم زیاد دست و پا گیر نیست.
اما در اپلیکیشنهای کلاینتی استفاده از این ابزار برای بهبود زمان آغاز به کار برنامه و یا کاهش Working Set درصورتیکه از چندین نسخه از برنامه با هم استفاده بشه، میتونه ارزش داشته باشه. البته تو برخی موارد حتی اگه از چندین نسخه از برنامه باهم استفاده نشه و تو هر لحظه فقط یه نمونه از برنامه درحال اجرا باشه، استفاده از این ابزار میتونه کاهش قابل ملاحظه ای تو اندازه Working Set برنامه داشته باشه.
علاوه بر این، اگه تمامی اسمبلی های یه اپلیکیشن و ریفرنسهای اونا توسط ابزار NGen.exe کامپایل شده باشن، CLR اصلا کامپایلر JIT رو بارگذاری نمیکنه که خودش باعث کاهش بیشتر Working Set برنامه میشه. البته اگه حتی یکی از اسمبلی های درگیر NGen نشده باشه و یا CLR به هر دلیلی نتونه از فایلهای NGenشده استفاده کنه، کامپایلر JIT بارگذاری میشه.
برای اپلیکیشنهای بزرگ که مشکلات مصرف بیش از حد حافظه و زمان زیاد بارگذاری اولیه رو دارن، مایکروسافت یه ابزار مخصوص تولید کرده. این ابزار که MPGO.exe (مخفف Managed Profile Guided Optimization) نام داره، اجرای یه برنامه رو آنالیز میکنه تا ببینه مثلا برای آغاز به کار به چه چیزایی نیاز داره. سپس اطلاعاتی که این ابزار تولید میکنه رو میشه به عنوان ورودی به ابزار NGen.exe داد تا بهینه سازی هایی رو تو فرایند کامپایل اعمال کنه. با اینکار برنامه سریعتر بارگذاری شده و Working Set کوچکتری خواهد داشت.
زمانیکه برنامه برای انتشار نهایی آماده شد، بهتره تا از این ابزار برای گردآوری داده های اجرای قسمتهای عمده برنامه استفاده بشه. این ابزار این داده ها رو به صورت یه پروفایل تو خود اسمبلی های برنامه ذخیره میکنه که بعدا در صورت اجرای ابزار NGen.exe، از این داده ها برای بهینه سازی قسمتهای تست شده استفاده میشه.
.: در ادامه درباره FCL یا Framework Class Library و CTS یا Common Type System بحث میشه.
CLR به زبان ساده - قسمت اول: پیشگفتار
CLR به زبان ساده - قسمت دوم: اسمبلی
CLR به زبان ساده - قسمت سوم: بارگذاری
CLR به زبان ساده - قسمت چهارم: اجرا
CLR به زبان ساده - قسمت پنجم: IL و بررسی کد
CLR به زبان ساده - قسمت ششم: NGen.exe
CLR به زبان ساده - قسمت هفتم: FCL و CTS
CLR به زبان ساده - قسمت هشتم: CLS
CLR به زبان ساده - قسمت نهم: کد مدیریت نشده
:.