Kennisdump

Gevoelsmatig zou je kunnen zeggen dat het hebben van vele kleine methodes trager werkt dan het hebben minder methodes die groter zijn. Niets hiervan is waar en dat heeft alles te maken met de manier waarop de .Net runtime werkt. De .Net runtime roept de JIT compiler aan om de IL gegenereerde C# code te compileren naar machine code. De gehele applicatie wordt namelijk niet in één keer gecompileerd naar machine code. Dit omdat dit vertragend werkt en omdat de kans bestaat dat er code is gecompileerd welke nooit zal worden aangeroepen. Om dit te voorkomen roept de CLR de JIT compiler aan op basis van methodes. Dit minimaliseert de opstartkosten en het voorkomt dat de applicatie vastloopt als later meer code moet worden geJIT. De ontwikkelaar kan dus de irrelevante code beperken door grote methodes op te hakken in kleinere methodes. Dit levert dus performancewinst op en bovendien brengen kleine methodes meer voordelen met zich mee: - Single Responsibility Pattern: Voor classes geldt da

In MVC zijn er verschillende manieren om data van de Controller in de view te krijgen. Eén mogelijkheid is om gebruik te maken van ViewData, TempData of de ViewBag. Het was niet geheel duidelijk wat nu precies het verschil is tussen deze datahouders, dus heb ik het even uitgezocht. ViewData wordt gebruikt in één controller en kan vervolgens weer worden opgevraagd vanuit de View. Als er in de controller een redirect zou plaatsvinden naar een andere action, dan verliest ViewData zijn waarde. public ActionResult Create() { // Sla waarde op in ViewData ViewData["Error"] = "Fout opgetreden bij het het aanmaken van ..."; // Redirect naar de index return RedirectToAction("Index"); } public ActionResult Index() { // De variabele error is leeg var error = ViewData["Error"]; } De ViewBag is geïntroduceerd in MVC 3 en heeft dezelfde eigenschappen als de ViewData (na een redirect is het weer een leeg object). Het gebruik van de ViewBag is

Alle programma's die worden opgestart, moeten in het geheugen worden geladen. Op de eerste plek probeert het OS het programma te laden in het RAM geheugen. Als er een programma wordt gestart en het RAM geheugen is vol, dan gaat het OS gebruik maken van virtueel geheugen. Dit houdt in dat het OS het RAM geheugen gaat combineren met virtueel geheugen. Het virtuele geheugen wordt opgeslagen op de harde schijf in een pagefile (pagefile.sys). Bij virtueel geheugen verplaatst het OS de data van het RAM geheugen naar het virtuele geheugen. Op deze manier komt er weer geheugen vrij in het RAM. Het lezen en schrijven van en naar het RAM geheugen is aanzienlijk sneller dan lezen en schrijven naar een pagefile (het virtuele geheugen). De grootte van de pagefile wordt automatisch geregeld door Windows. Standaard is dit 1,5 keer zo groot als het aanwezige RAM geheugen. Hoewel deze grootte door Windows is bepaald, kan dit ook handmatig worden ingesteld. bronnen: http://windows.microsoft.co

De Garbage Collector (GC) zorgt voor het toewijzen en vrijgeven van geheugen voor de applicatie. Elke keer als er een object wordt aangemaakt dan wijst de common language runtime (CLR) geheugen van de managed heap toe aan dit object. Een heap is een verzameling van aaneengesloten stukken geheugen. Dit geheugen wordt tijdens het starten van het proces (applicatie) gereserveerd door de runtime en is bij aanvang helemaal leeg. De grootte van de heap is afhanklijk van een aantal factoren: de .NET Framework versie, is het een 32 of 64 bits systeem en in welke mode wordt de GC uitgevoerd, server of werkstation. De managed heap houdt een pointer bij waar het volgende object opgeslagen moet worden. Een heap kan meerdere segments hebben. Als een segement vol is, wordt er binnen dezelfde heap een nieuw segment aangemaakt. Garbage collector roots Een object wordt pas opgeruimd door de GC als deze niet meer direct te benaderen is vanaf de GC root. De GC kent vier verschillende roots: Lokale va