*bump*
Anyone ?

U svakom slucaju probacu da li ce ngen da odradi pri instalaciji na klijentovom racunaru ;)

A sto se uopste petljas sa time?

Onako, igram se :P
To make my assemblies (almost) native fast, man :)

.NET nije kao Java ili VB6, dakle nije interpreter. Svaki put kad se asembli ucitava JIT kompajler ngen-uje kod ako ngen image nije direktno dostupan u kesu. Dakle tvoji asembliji su vec native fast, man ;)

Naravno da nije interpreter, ali radi se o sasvim drugoj stvari :) Naime, ngen se koristi da PREkompajlira asembli i da sacuva dobijeni rezultat u kes, da bi se izbeglo JIT-anje svaki put pri koriscenju programa. Problem je u tome sto se na mojoj kucnoj masini taj kes nekako osteti, ili se ne kreira kako bi trebalo (iako se kes programa uredno upise u C:\Windows\assembly\NativeImages_v[VERZIJA] ).

Evo kratkog "testa" sa masine na kojoj sve radi ok:
1. Instalirao sam .NET SDK
2. Download-ovao sam Vista Manager (.NET program) i pokrenuo ga nekoliko puta.
3. Korstio sam Process Explorer da "ispitam" performanse JIT-a



4. Generisao sam image kes na sledeci nacin: ngen install VistaManager.exe
5. Korstio sam Process Explorer da "ispitam" performanse JIT-a :)



Pokusajte i sami, pa uporedite rezultate.

Dalje, ne znam da li ste primetili da se posle instalacije Visual Studia ili update/instalacije .NET framework-a, itd. proces mscorsvw.exe pokrene i zapocne da "radi nesto u pozadini". Naravno, to je .NET optimization service koji vrsi prekompilaciju najvaznijih asemblija koji se nalaze u queue (ngen install [assembly] /queue).

:bye:

To je inace velika prevara
Do pre .NET2 ngen generisani asembliji su imali veliki problem sa bindingom metoda, tj, posto u trenutku kreiranja native image-a nijedan metod nije znao ko ce ga pozivati niti gde su metode koje ce pozivati iz drugih asemblija pa su svi pozivi bili realizovani od strane ngen-a preko malih "stub" metoda koju su sracunavale virtuelne adrese stvarnih metoda i obavljale virtuelni poziv, sto ce reci svaki poziv metoda je imao dodatni trosak CPU vremena pri svakom mogucem pozivanju propertija i metoda. Dakle nisi platio na mostu i preskocio si JIT, ali zato placas na cupriji tokom celokupnog zivota aplikacije. JIT iako malo jednokratno uspori ucitavanje asemblija, u trenutku kad se aktivira zna sve virtuelne adrese i ne generise te stub-ove.

.NET2 ngen je dodao mogucnost za hardbinding gde se pozivi realizuju direktno virtuelnim pozivima, ali je problem sto da bi to funkcionisalo CLR mora da ucita SVE asemblije odjednom, tako da kad ti aplikacija koristi dosta asemblija koji se ne ucitavaju odmah na pocetku vec po potrebi kasnije (asembli se nece ucitati dok se ne referencira neki tip iz njega), zapravo gubis i taj mali dobitak na vremenu koji ti preskakanje JITa daje jer program nece poceti dok se svi asembliji ne ucitaju, sto ume da potraje dosta duze nego startup JITovanje par pocetnih asemblija.

Moj predlog, osim ako ti asembli ne ide u GAC, nemas potrebe da ga ngen-ujes.

Hmmm, ne znam, ali sudeci po svemu sto sam procitao o ngen-u mi se cini da aplikacija ima kraci "cold-start" (nema jit-anja), a i manji memory footprint (ngen image moze da se "memorijski deli", za razliku od jit-anog msil-a).
Opet, sve je to diskutabilno i zavisi od use case-a i zato bih zeleo da detaljno istestiram performanse (ali prokletinja jednostavno ne radi na mojoj masini :)

Sto se tice hardbinding-a, on me ne brine posto broj mojih lazy/delay loaded assembly-a koje koristim nije veliki; vise me brine rebasing image-a (pri update-ovanju, patch-ovanju itd.) i potreba za "pazljivim odredjivanjem" base address-a da se working set size ne poveca, kao i naravno citav throughoutput ngen-ovane aplikacije.

Sve u svemu, preinstaliracu sistem pa cu probati.

Ah, da, umalo da zaboravim ovde http://msdn2.microsoft.com/en-us/magazine/cc163610.aspx se nalazi sjajno i detaljno objasnjenje "svih aspekata ovde pominjanih" :)

To NGEN or not to NGEN, that is the question ... :P

:bye:

rebasing moze da se desi SAMO ako koristis NGEN. JIT vec zna gde ce smestiti modul i dinamicki odredjuje base adresu za native asembli i samim tim vec ima minimalni working set ako DLL nije deljen izmedju vise aplikacija A ako asembli hoces da sharujes izmedju vise aplikacija, onda mu je mesto u GACu i onda treba da bude NGENovan, ali ces i onda tesko da nadjes "sigurnu" base adresu koja se nece poklati sa nekim drugim GAC asemblijem ili native DLLom koji u pozadini koristi neki unsafe asembli a za koji ti ni ne znas. Ako assembli nije deljen onda jednostavno nemas nikakve direktne koristi, iako ce on uci u shared DLL prostor i nece biti deo tvog private working set-a on ce i dalje biti ucitan negde u memeoriju i bice deo necijeg private working set-a.

Stvarno, mislim da zestoko gubis vreme sa ovim. Taj tekst je ok i sve sto pise tamo vazi, bar u teoriji, i mogu da razumem da se takvim stvarima pokloni paznja u huge enterprise projektima gde imas gomilu asemblija od po stotinjak megabajta i slicno, ali za realnu upotrebu .NETa jednostavno je bezveze gubiti vreme sa tim. Uostalom taj tekst vise sluzi toj autorki da pokaze kako i oni tamo u tom timu rade nesto korisno

Kao sto si ovo uradio sa JIT CPU vremenom, izvuci i velicine private working set-a za aplikaciju sa i bez ngen-a pa vidi koliko si desetina kilobajta ustedeo Pa to uporedi sa kompletnim setom, to bi trebalo da te uputi na uzaludnost tog posla.