[ASP.NET]rebooten == opnieuw compilen

[Dikkie]

Elke keer als ik mijn pc reboot of aanzet, en ik vraag een asp.net pagina op van diezelfde pc, dan duurt het een tijdje voordat die zichtbaar is.

Ik neem aan dat de pagina opnieuw gecompiled moet worden, maar hoe kan ik dit uitzetten, want het is wel irritant aangezien ik mijn pc 's nachts uit heb staan, en dan 's morgens weer een tijd moet wachten zodat al mijn asp.net pagina's weer gecompiled zijn.

[gorgi_19]

Erhm.. Niet? Hij moet bij het opstarten (van een ASP.Net pagina) namelijk de .dll-bestanden in het geheugen laden.

Een andere oplossing zit er niet in (of je moet je pagina's niet compilen.. )

Voor de duidelijkheid: Je compiled geen pagina's bij het laden van een pagina.

[ReLight]

ASP.Net is een intermediate language , en word gecompileerd naar MSIL.
Bij de 1ste uitvoer worden de pagina's wel degelijk 'gecompileerd' naar de machine taal van het platform waar ze op uitgevoerd worden door middel van de CLR, common language runtime.

ASP.Net pagina->MSIL->CLR

Maar naar mijn weten doen deze dat enkel voor die 1ste keer, waarom dit dan gebeurd na een reboot snap ik niet, bedoel je inderdaad niet de 1ste keer dat je uberhaubt EEN asp pagina oproept ? Of is het bij elke asp pagina die je voor het eerst ophaald na een reboot ?

[mbravenboer]

ReLight: ASP.Net is een intermediate language , en word gecompileerd naar MSIL.

Je terminologie is een beetje verwarrend: over het algemeen wordt MSIL is een intermediate language genoemd omdat de IL sterk overeenkomt met de klassieke intermediate representations van compilers: back-end onafhankelijk, op sommige punten abstracter dan instructies van en processor, op sommige punten juist atomairder dan de instructies van een processor. Tot slot heet IL niet voor niets Intermediate Language .

Bij de 1ste uitvoer worden de pagina's wel degelijk 'gecompileerd' naar de machine taal van het platform waar ze op uitgevoerd worden door middel van de CLR, common language runtime.

Dat is overigens niet strikt noodzakelijk zo: MSIL kan ook geinterpreteerd worden, ook al doet het .NET Framework van Microsoft dit niet. Implementaties voor kleine devices zullen dit waarschijnlijk wel doen omdat de kosten van een just in time compiler daar te groot zijn. Mono kan ook in slechts interpretatie mode worden gebruikt.

Maar naar mijn weten doen deze dat enkel voor die 1ste keer, waarom dit dan gebeurd na een reboot snap ik niet

Ik heb weleens gehoord dat de eerste release van .NET geen native code cached voor assemblies. Dit zal je zelf expliciet moeten doen via ngen. Dit zou in een latere release wel ingevoerd worden. Ik weet niet zeker of dit correct is en ik weet ook niet of het wellicht ondertussen al wel is ingevoerd.

[Verwijderd]

gorgi_19 schreef op 04 september 2002 @ 01:43:
Erhm.. Niet? Hij moet bij het opstarten (van een ASP.Net pagina) namelijk de .dll-bestanden in het geheugen laden.
Een andere oplossing zit er niet in (of je moet je pagina's niet compilen.. )

Dit is idd wat er gebeurd. Is overigens ook zo bij andere webapplicaties die bv van COM objects en ASP gebruik maken: ook die moeten initieel de dlls die gebruikt worden inladen bij de 1e actie op de webapplicatie.

Indien je niet wilt wachten kun je eventueel een .net applicatietje bouwen die niets doet en bij het starten van windows wordt gestart. De DLL's zitten dan in memory en je hebt de delay niet.

Voor de duidelijkheid: Je compiled geen pagina's bij het laden van een pagina.

Wel bij de 1e keer dat je ze aanroept na het schrijven van bv web.config

[Verwijderd]

mbravenboer schreef op 04 september 2002 @ 08:29:
[...]
Ik heb weleens gehoord dat de eerste release van .NET geen native code cached voor assemblies. Dit zal je zelf expliciet moeten doen via ngen. Dit zou in een latere release wel ingevoerd worden. Ik weet niet zeker of dit correct is en ik weet ook niet of het wellicht ondertussen al wel is ingevoerd.

Winforms applicaties worden geJIT, dus de compiled code wordt niet bewaard. Je hebt initieel een delay dus. Je kunt mbv ngen.exe de code naar native code compileren, de applicatie start dan een heel stuk sneller, maar je hebt geen JIT. MS gaat in de toekomst ngen uitbreiden met een betere optimizer, wellicht een die ook at runtime nog JIT, maar zeker is dit niet. Het cachen van JITted code is volgens MS niet zo nuttig, want dat is compiled code die in die instance op dat moment efficient was, die cachen hoeft geen snelheidswinst te betekenen in een andere instance. Wel is het zo dat de 1e versie van de tools allemaal niet op hun top zitten: de JIT bv kapt snel een compile actie af en werkt nog niet optimaal samen met de compiler (die wel erg weinig optimaliseert)

[mbravenboer]

Otis: MS gaat in de toekomst ngen uitbreiden met een betere optimizer, wellicht een die ook at runtime nog JIT

Ik hoorde op de Mono mailing list een keer flinke kritiek op de aanpak van optimalisatie in ngen versus de optimalisatie in de jitter. Ze schijnen beide dezelfde optimizer te gebruiken. Gezien de volledig verschillende behoeften at runtime werd dit als onverstandig afgeschilderd, wat op zich niet bepaald verbazingwekkend is. Je zou sowieso verschillende niveaus van optimalisatie verwachten. Kan ik uit jouw woorden opmaken dat ze het nu dus wellicht gaan splitsen?

Ik ben trouwens een beetje verbaasd over je stukje over het (niet) nut van het cachen van native gecompileerde code. Ik dacht juist begrepen te hebben dat deze mogelijkheid als een van de sterke punten werd gepresenteerd? Volledige just in time compilatie zoals in .NET zorgt nogal voor een opstartprobleem, wat er ook al is in de JVM. Vandaar dat daar gekozen is voor mixed-mode executie en bij het opstarten begint de JVM dus met interpreteren. Door native gecompileerde code voor assemblies te cachen, kan je deze opstarttijd problemen toch voorkomen lijkt mij? Het nut van deze aanpak is ook vaak besproken voor de JVM, maar ik heb nooit echt duidelijke argumenten voor of tegen gehoord.

[ReLight]

We leren elke dag weer bij

Maar gaat dit ook op voor dll's, echte asp applicaties dus ?
Moeten die ook elke keer opnieuw geconverteerd worden ?

[Verwijderd]

ReLight schreef op 04 september 2002 @ 09:49:
Maar gaat dit ook op voor dll's, echte asp applicaties dus ?
Moeten die ook elke keer opnieuw geconverteerd worden ?

Een .net app moet de CLR etc in process laden. Dit kost tijd wanneer die dlls niet in core zitten en dus van disk moeten worden geladen. Dit is de delay die de topicstarter ziet.

Daarnaast worden winform/console apps geJIT en dat gebeurt at runtime. Start je zo'n applicatie op, dan wordt de code bij de start van de executie gecompileerd door de JIT, kleine stukjes per keer. Dit gebeurt elke keer opnieuw, wanneer een applicatie uit memory gaat. ASP.NET pages worden pre-compiled gecached. Assemblies die in ASP.NET worden gebruikt worden elke keer geJIT. Wil je dit niet, dan gebruik je ngen.exe en genereer je native code van die assemblies. Je wint er iets mee in sommige gevallen maar meestal is het trager op den duur.

Normale ASP pages worden altijd geinterpreteerd. COM objects in asp pages worden geinstantieerd door een 'class factory'. Dit is een class die in de COM dll zit en instances maakt van het door jouw aangevraagde COM object. Die DLL moet je dus wel inladen. Laadt die DLL weer andere DLL's in (bv de ADO dll's) dan worden ook die bij de start ingeladen. De delay is zeker merkbaar. Als ik de 1e page opvraag van een met mn CMS gebouwde site, dan kraakt de server een 3, 4 tal seconden voordat de page zichtbaar wordt: COM dll's worden geladen (ADO, VB/C++), SQLserver moet wakker worden, etc etc. Eenmaal geladen merk je hetniet meer, want zodra een dll in memory is kan deze gemapped worden in meerdere processes. Wellicht leuk om te lezen zijn de artikelen over DLL loading en hoe deze in process worden gemapped, staan in de MSDN.

[Verwijderd]

mbravenboer schreef op 04 september 2002 @ 09:42:
[...]
Ik hoorde op de Mono mailing list een keer flinke kritiek op de aanpak van optimalisatie in ngen versus de optimalisatie in de jitter. Ze schijnen beide dezelfde optimizer te gebruiken. Gezien de volledig verschillende behoeften at runtime werd dit als onverstandig afgeschilderd, wat op zich niet bepaald verbazingwekkend is. Je zou sowieso verschillende niveaus van optimalisatie verwachten. Kan ik uit jouw woorden opmaken dat ze het nu dus wellicht gaan splitsen?

Dat idee had ik wel ja. Er is een artikel over verschenen op de MSDN site tijdje geleden. ngen.exe is nu in zn 1e versie en ze hebben geprobeerd daar een wat werkbare versie van te maken, maar de grote sprong voorwaards moet nog komen. Vooral het gemis van een JIT at runtime is merkbaar bij veel apps die zijn ge'ngen't.

edit:

http://msdn.microsoft.com.../html/dotnetperftechs.asp
http://msdn.microsoft.com...t/html/dotnetperftips.asp

Wat vooral verbazing oogste was de beperkte optimalisaties in de JIT op dit moment, en vooral het gebrekkige voorwerk dat wordt verricht door de compilers (en bv ook door ngen die perfect langdurige optimalisatie analyses kan doen zodat de JIT sneller beslissingen kan nemen wat tijd scheelt). Ook hier willen ze veel verbeteringen aanbrengen, ze hebben het nu allemaal wat conservatief gehouden, een aanpak die ik wel begrijp. Een JIT moet nu eenmaal niet te lang doen over een optimalisatie en de threshold die je kiest wanneer wel en wanneer niet een optimalisatie wordt uitgevoerd is bepalend voor de snelheid waarmee alles draait, die wat conservatief stellen scheelt je wellicht top performance in sommige gebieden maar vermijdt ook trage performance in wellicht veel gebieden.

Ik ben trouwens een beetje verbaasd over je stukje over het (niet) nut van het cachen van native gecompileerde code. Ik dacht juist begrepen te hebben dat deze mogelijkheid als een van de sterke punten werd gepresenteerd? Volledige just in time compilatie zoals in .NET zorgt nogal voor een opstartprobleem, wat er ook al is in de JVM. Vandaar dat daar gekozen is voor mixed-mode executie en bij het opstarten begint de JVM dus met interpreteren. Door native gecompileerde code voor assemblies te cachen, kan je deze opstarttijd problemen toch voorkomen lijkt mij? Het nut van deze aanpak is ook vaak besproken voor de JVM, maar ik heb nooit echt duidelijke argumenten voor of tegen gehoord.

Dit dacht ik ook, dat ze dus alle native code cachten. Dit is echter niet het geval. ngen cachet dus native code maar JIT niet, de JIT runt de code maar cachet niet. Een uitzondering zijn de ASP.NET pages / classes, die wel pre-compiled gecached worden. Een reden hiervoor is denk ik dat deze niet echt in aanmerkingkomen voor JITting, maar het compilatieprocess wel lang kan duren. (mn dual p3-933 doos met 512MB ram en serverworks chipset heeft af en toe soms wel 3 seconden nodig voor het compileren van de 1e page )

Als je ziet wat voor optimalisaties de csc compiler bv uitvoert, dan is dat echt helemaal niks. De JIT voert op dit moment ook maar weinig echte diepe optimalisaties uit, meer het rechtbreien van crappy code. Als je dat dus al niet gebruikt, dan is het optimaliseren dus in feite niet echt ver doorgevoerd op dit moment, maar er is ruimte voor verbeteringen.

vziw zijn alle .NET libs van MS wel met ngen gecompileerd, die JIT je dus niet mee. Of dit een goed ding is weet ik eerlijk gezegd niet, maar ze zullen dit ongetwijfeld getest hebben

[Dikkie]

Verwijderd schreef op 04 september 2002 @ 09:29:
[...]


Indien je niet wilt wachten kun je eventueel een .net applicatietje bouwen die niets doet en bij het starten van windows wordt gestart. De DLL's zitten dan in memory en je hebt de delay niet.

Dus gewoon een console applicatie?

[Verwijderd]

Ja of een windows service gemaakt in .NET

[mbravenboer]

Ik kwam net deze tegen:
Code generation: C# vs. VB.NET
Op zich boeit het verschil wat hier naar voren komen mij niet bepaald, maar wat mij met name opviel is dat volledig triviale constante propagatie hier al geeneens wordt uitgevoerd, laat staan enigzins complexere zaken. Dit is overigens bij de Java compiler van Sun ook het geval (die doet wel een beetje aan constant propagation trouwens).

De redenatie schijnt hier te zijn dat er toch een JIT compiler is en dat de front-compilers (C# -> IL, VB .NET -> IL, Java -> Java Bytecode) dus maar zo weinig mogelijk moeten doen. In feite komt het slechts neer op een stukje type-checking en het rechtstreeks vertalen naar CIL of Java Bytecode.

[Verwijderd]

precies. dat viel mij ook al op: de zeer beperkte optimalisaties die in de C# compiler zitten. Nu is het wel zo dat de C# compiler (net als de VBcompiler) erg rap is (duh, hij doet alleen wat lex-en en een beetje yacc-en ) in vergelijking met bv de VC++ compiler, dus veel optimalisaties doen levert een trage compiler op, maar ik denk dan: waarom geen optimizer achter de release build stoppen?

[mbravenboer]

Misschien komt het omdat er zoveel zaken beter at runtime kunnen gebeuren dat ze de paar zaken die je at compile time zou kunnen doen, maar helemaal later voor wat het is. Inlining bijvoorbeeld: typisch iets wat je liever doet als je inzicht hebt over de beschikbare klassen en de (inheritance) structuur daarvan. Na de inlining zou je eigenlijk graag weer onder andere constante propagatie willen doen.

Op zich niet echt een enorm goed excuus om toch niet alvast wat at compile time te doen, maar het kan een reden zijn .

[Verwijderd]

wellicht zit compile-time inlining de optimizer at runtime dermate in de weg dat het eerder averechts werkt. Wat ik me kan voorstellen is dat de compiler at compile-time puur zaken zo neerzet / extra info genereert, zodat de JIT beter/sneller zn werk kan doen. De echte optimalisaties zitten toch in analyses van control-flow, en dat is at runtime beter te doen dan at compiletime. Wat je dan in feite zou moeten hebben is een JIT-logger die runtime-analysis logt voor een optimizer die deze informatie weer verwerkt in een beter geoptimaliseerde executable. Dit kost wellicht veel tijd, maar kun je bv schedulen op een andere bak of tijdens een idle-moment.