http://support.microsoft.com/kb/2570538 geeft aan:
" Symptoms - When you install an update for the Microsoft .NET Framework 4, the Native Image Generator (NGen.exe) uses a high percentage of the CPU cycles on the computer for a long time. This time varies with how many Native Images are installed on the computer."
" Symptomen - Wanneer u een update installeert voor Microsoft .NET Framework 4, gebruikt Native Image Generator (NGen.exe) gedurende lange tijd een groot percentage van de CPU-cycli op de computer. De tijd varieert met het aantal Native Images die op de computer zijn geïnstalleerd."

Ik neem aan dat dat betekent dat dat probleem veel zwaarder aankomt op een oudere PC met een relatief trage cpu, dan op een moderner systeem met een snellere cpu?

Ik kan me niet herinneren of ik er iets van heb gemerkt. Mijn Microsoft.NET\Framework\v4.0 folder is van 25 augustus 2010, zie ik, te lang geleden om me nog te herinneren of de update traag of anderszins problematisch was.

En als je nou wat extra geheugen koopt van 1 GB, zal het dan niet sneller gaan?

Ja, dat zal zeker uitmaken.

Het probleem zit niet zozeer in de installatie van .Net 4 zelf, maar in de updates daarna. Hieronder het rijtje in de volgorde waarin ze mij werden aangeboden (de eerste bovenaan), waarbij ik er telkens maar een enkele of een paar kreeg aangeboden en dan weer terug moest naar https://www.update.microsoft.com/:

http://support.microsoft.com/kb/982670 (.NET 4.0 client profile zelf)
http://support.microsoft.com/kb/2478663 == www.microsoft.com/technet/security/bulletin/ms11-039.mspx
http://support.microsoft.com/kb/2572078 == technet.microsoft.com/security/bulletin/MS11-078
http://support.microsoft.com/kb/2518870 == www.microsoft.com/technet/security/bulletin/ms11-044.mspx
http://support.microsoft.com/kb/2539636 == www.microsoft.com/technet/security/bulletin/MS11-069.mspx
http://support.microsoft.com/kb/2533523 (Reliability Update 1 for the .NET Framework 4)
http://support.microsoft.com/kb/2468871 ("Update for the .NET Framework 4")

De meeste updates zijn van afgelopen juni of later.

Nee, er zit 1GB in deze PC maar dat wordt bij lange na niet gebruikt (tijdens die updates).

Ook in eerdere PC's (met 2 of >3GB geheugen) viel me op dat .NET 4 updates veel tijd kostten. Wel is de schijf in de PC waar ik vandaag aan geprutst heb erg traag (nog een 80 giegje en toen ie nieuw was al geen uitblinker qua snelheid). Overigens is C:\WINDOWS\ASSEMBLY\ op die PC ondertussen aangegroeid tot ca. 480MB, daarbij heb ik enkele keren gemerkt dat inloggen na koude start erg lang duurde (met een boel schijfgeratel). Kennelijk wordt er vanalles in die cache bijgewerkt, ook bestanden die daar al eerder stonden zijn ondertussen geupdate (19:45 de laatste, en dat was ruim 2 uur na de laatst geinstalleerde update).

Ik vermoed dat CPU en vooral schijfsnelheid (beide in meer of mindere mate gehinderd door een virusscanner) hierbij wel een grote rol spelen. Overigens versterkt het e.e.a. mijn indruk dat PC's trager worden met elke versie van het .NET framework dat je toevoegt.

PS voor een aantal URL's moest ik http:// weghalen om te kunnen posten (bevatte teveel URL's).

Ah, dank je.
Daar heb ik dan niets bijzonders mee gemerkt.
Mogelijk doordat m'n processor en schijven simpelweg snel genoeg zijn.
Maar wanneer dat probleem op oudere systemen met tragere cpu en schijven wél de kop opsteekt, lijkt me dat hoogst hinderlijk.
Ik ben met jou benieuwd of iemand die Fix it of commands heeft toegepast en of het hielp.

De traagheid zit hem in het opnieuw compileren/genereren. Dot NET is een enorme rotzooi (ik zeg het hoe het is) en het zorgt bepaald niet voor een verbetering van Windows.

Microsoft is opnieuw ontspoort met hun drang naar het maken van waterhoofd libraries.

Eens...
En ik heb inmiddels de updates hiervan uit gezet. Iedere keer dat ik de update van .Net startte kwam Windows uiteindelijk met onbekende errors waar ik niets mee kon.

ik had dit gisteren toevallig ook bij een installatie van een oude pc met windows xp sp3. Dacht op een gegeven moment dat hij was vastgelopen en ben toen maar wat anders gaan doen. Toen ik later terug kwam was hij klaar. De update heeft wel meer dan 1 uur geduurd.

De wet van Wirth.
Het enige voordeel is dat na de precompile fase de .net vuiligheid in ieder geval op een acceptabele snelheid zal draaien, ook op die wat oudere hardware.
Redenen:
1. swapgedrag want je hebt te weinig heugen.
2. Je schijf is een langzame
3. (echt pas derde plaats: je CPU is niet een van de nieuwste.

Aanbevolen in volgorde van effect:
1. twee GB er in prikken (als je het nog kan vinden)
2. nieuw of gebruikt recenter schijfje er in, 5400 of 7200 ipv 4200
3. Pensioneren die bak. maak er maar een servertje van.

Op een XPSP3 PC met .Net 1.1, 2 en 4 en C# en C++ uit Visual Studio Express Edition staat ruim 900MB onder C:\Windows\Assembly.

Onder C:\Windows\Assembly\NativeImages_v4.0.30319_32\ alleen al staat ruim 400MB. Alle bestanden hebben een creatie datum en tijd van kort na het starten van Microsoft updates (12 oktober) omstreeks middernacht of van de volgende ochtend. Als ik de tijden optel was er kennelijk 9,5 minuut nodig om al deze bestanden opnieuw te genereren. Waarschijnlijk heeft Windows tussendoor nog wel andere dingen gedaan, maar dit maakt wel duidelijk dat hoe meer .NET apps je op je PC hebt, hoe langer elke gerelateerde update duurt.

En dat is niet goed, gebruikers zijn al voldoende update-moe. Dit leidt er onherroepelijk toe dat mensen updates gaan uit- of afstellen.

Ik geloof er overigens geen barst van dat de Fix-Its in http://support.microsoft.com/kb/2570538 iets uitmaken, integendeel. Het advies is deze te draaien direct voordat je een update start. Hoewel het zou kunnen dat de update die Assembly cache vervolgens niet helemaal leeg maakt, is de kans groot dat er genoeg dependencies zijn om dat wel te doen. Dan ga je met je Fix-It dus nog meer tijd verspillen dan nodig.

Ik kan me niet aan de indruk onttrekken dat Microsoft in haar naïviteit meende bugvrije .NET libraries te kunnen opleveren en er geen rekening mee gehouden heeft wat de consequenties van de onvoorziene updateprocessen voor gebruikers zijn.