NGen.exe – Native Code Generator

Özgür Belül — Fri, 27 Jun 2008 21:49:50 GMT

.Net Framework ile birlikte gelen bir araç olan NGen.exe kurulum anında uygulamanın IL kodlarını makine diline çevirmeye yarıyor. Kod kurulum esnasında makine diline çevrildiği için çalışma anında JIT derleyicilerin derleme yapmasına gerek kalmadığından performans avantajı sağlanıyor.

Makine diline çevrilen kod aşağıdaki gibi bir dizine kaydediliyor.

C:\Windows\Assembly\NativeImages_v2.0.50727_32

Son dizin ismindeki rakamlar CLR versiyonunu ve kodun 32bit işletim sistemi için oluşturulduğunu belirtiyor.

Peki bu kod nasıl çalışıyor? CLR bir assembly yüklediğinde NGen.exe ile oluşturulan dosyanın olup olmadığını kontrol ediyor. Eğer dosya varsa CLR bunu kullanıyor ve çalışma anında derleme işini aradan çıkartıyor dosya yoksa CLR standart prosedürü uygulayıp çalışma anında kodu makine diline çeviriyor.

Managed kod avantajlarından (Garbage collection, tip güvenliği, vs. ) yararlanıp dezavantajlarından kurtulmak (Performans kaygıları) ilk anda kulağa hoş geliyor. Ancak gerçekte işler göründüğü kadar iyi değil.

Öncelikle birçok yazılım geliştiricinin düştüğü hata sadece NGen kullanılarak çevrilmiş kodu çalıştırmanın yeterli olacağıdır. Ancak bu mümkün değil. CLR’ın çalışma anında reflection, serialization gibi işlemler için assembly’nin metadatasına erişmesi gerekiyor. Bu sebeple IL kodu da NGen tarafından çevrilmiş kodla birlikte olmalıdır. Bununla birlikte CLR aşağıdaki sebelerden dolayı ya da bir şekilde NGen tarafından çevrilmiş kodu kullanamazsa IL kodunu çalışma anında derlemektedir.

CLR, NGen tarafından çevrilmiş kodu yüklediğinde IL üzerinden bir takım özellikleri mevcut çalışma ortamıyla karşılaştırır. Bunlardan bazıları: İşlemci tipi, CLR versiyonu, Uygulamanın build şekli (Release, debug, optimized debug, vs.), MVID (Assembly Module Version ID), vs. Eğer bu özelliklerden herhangi birisi uyumsuz olursa CLR NGen tarafından çevrilmiş kodu çalıştırmaktan vazgeçip çalışma anında IL kodunu makine diline çeviriyor. Burada şunu da belirtmekte fayda var NGen.exe update modunda çalıştırabilirsiniz böylelikle son kullanıcı framework’ün yeni bir service pack’ini kurduğunda service pack kurulum programı otomatik olarak NGen.exe’yi çalıştırabilir ve dosyaların bilgisayarda yüklü son CLR versiyonu ile uyumluluğu sağlanmış olur.

Diğer bir nokta ise assembly dosyaları standart Windows PE (Portable Executable) dosyalarıdır ve belirlenmiş bellek adreslemelerine sahiptirler. Windows NGen tarafından çevrilmiş kodu çalıştırdığında bellek adreslemesi yapılan alanları kullanıp kullanamadığına bakar. Eğer bir sebepten dolayı belirlenmiş adresleri kullanamıyorsa Windows uygulamadaki bellek adreslemesini yeniden yapılandırır. Bu oldukça zaman tüketen bir durumdur çünkü öncelikle tüm uygulama belleğe alınır ve burada düzeltmeler yapılır. Bununla birlikte değiştirilen tüm dosyalar içinde bir yedekleme dosyası oluşturulur ki bu da bir başka maliyettir. Diğer bir araç olan CSC.exe’nin (C Sharp Compiler) /baseaddress komutunu kullanarak iyi bir bellek adreslemesi yapma şansına sahip olabilirsiniz. Şans diyorum çünkü malesef Microsoft bu konuda pek yardımcı olmuyor. JIT kullanılarak derlenen kodlar için bunların hiç birisi problem değil çünkü doğru bellek adres referansları çalışma anında hesaplanıyor.

Diğer bir eksi ise kodlar çalışma anında oluşturulmadığından oluşturulmuş kodlar ortam hakkında çalışma anında derlenenler kadar bilgiye sahip olamıyor.

Özellikle sunucu taraflı uygulamalarda NGen kullanmak oldukça gereksiz çünkü performans sorununu, çoğu zaman kullanıcılar bu yavaşlığın farkında bile olmazlar, sadece ilk kullanıcı yaşıyor. Bir çok sunucu uygulamasında kodun sadece bir instance’ı gerektiğinden diğer kullanıcılar için böyle bir etkilenme yaşanmıyor.

Uygulamanızda NGen kullanmayı düşünüyorsanız NGen tarafından çevrilen kodlarla çalışma anında çevrilenler arasında mutlaka karşılaştırma yapın ve hangisinin daha hızlı olduğundan emin olun.