[.NET] Performance (nog verder) verbeteren

[st0p]

ik heb de afgelopen week een benchmarkbuild van mijn VJ-app in elkaar gesleuteld. de resultaten ervan zijn wisselend qua gunstigheid, ik heb overall niks te klagen maar het ziet er naar uit dat ik 1500 regels code weg kan flikkeren omdat ze de snelheid toch aardig naar beneden halen. Dat doet verder ook niet echt terzake, waar het mij om gaat is het volgende:

herhaaldelijk testen op verschillende pc's maar met dezelfde input toont aan dat als ik één variable een envoudig script meegeef (script is in dit geval een echt stukje C# wat on-the-fly gecompileerd word en voor ieder nieuw frame uitgevoerd word) de gemiddelde framerate 4 a 5 procent toeneemt. Hoewel volledig tegen mijn verwachtingen in (ik zou verwachten dat scripts de boel vertragen) is dat natuurlijk nooit weg

Heeft iemand enig idee hoe dit kan? zou de .NET Runtime door het script de variable ergens cachen? indien dit het geval is, kun je dit gebruiken (misbruiken) om de snelheid nog verder op te krikken?

Aangezien we het nu toch over performance hebben onder .NET: het valt me op dat mijn programma een paar seconden na het opstarten ervan altijd een keer een fractie van een seconde "hikt". Ik heb al met intel's vtune profiler geozcht wat dit zou kunnen veroorzaken maar tot op heden niks gevonden. Niet dat dit "hikje" een groot probleem is maar het zou mooi zijn als ik het weg kon werken... ik gebruik nog de 1.1 compiler (wil binnenkort overstappen op 2.0), in combinatie met managed directx 9.0c. zowel onder de development versie als de redistributable van directx is er sprake van het hikje. Is er misschien iemand die me een hint kan geven van waar ik zou kunnen zoeken naar de oorzaak?

Als laatste: het valt me op dat het compilen van MSIL naar echte assemblie soms ook eventjes het renderen vertraagt. dit gebeurt uiteraard voor iedere methode maar een keer dus ook dit is niet een enorm probleem. toch zou ik het prettig vinden om ook dit op te lossen. Een oplossing zou zijn om de methodes tijdens initialisatie aan te roepen. Alleen zou dit ook betekenen dat er wat schermpjes tevoorschijn komen en weer verdwijnen. is er een manier om ervoor te zorgen dat alles bij het opstarten al wordt gecompileerd van MSIL naar machinecode?

alvast bedankt en mocht er iemand interesse hebben: hier staan 2 screenshots van het progje in actie:
http://www.frankdeweger.nl/fotodump/naamloos.jpg
http://www.frankdeweger.nl/fotodump/naamloos2.jpg

[H!GHGuY]

dat hikken kan wel eens zijn omdat er nog ergens een assembly moet gelinkt worden met late-binding, wat code moet geJIT worden of iets dergelijks... hou eens het "output" venster van VS.NET in de gaten of er daar niet nog een DLL geladen wordt of zo.

wat dat JIT-compilen betreft: als'k me niet vergis wordt dit slechts de allereerste keer dat je je programma start gedaan en wordt de machine-code dan gecached.
Ik merk toch alleszins dat tijdens de eerste run van nieuw gecompilede code het starten wel een merkbaar aantal seconden langer duurt dan wanneer ik hetzelfde programma daarna nogmaals start.

[ Voor 10% gewijzigd door H!GHGuY op 09-12-2005 20:33 ]

[Woy]

Er is een Tooltje wat standaard meegeleverd wordt wat een assembly compleet can compileren naar Machine code. Je kan dit al op je eigen pc doen maar volgens mij is het ook mogenlijk om dit op de machine van de eindgebruiker te doen want volgens mij wordt het tooltje met het framework meegeleverd. ( Volgens mij heet het tooltje ngen.exe )

Je zou dus een Assembly kunnen maken die eerst de uit te voeren assembly "Compileert" naar machine code en die daarna uitvoert. Hetgene waar je hikje verder nog vandaan kan komen is natuurlijk dat je nog niet alle data voor je applicatie geladen hebt. Het is dan ook van belang om te zorgen dat je al je data gaat laden voordat je begint met het renderen.

[ Voor 5% gewijzigd door Woy op 09-12-2005 23:09 ]

[misfire]

Als je verder niks aparts doet is het "hikken" waarschijnlijk een "full" garbage-collect cycle. De CLR Profiler is een goede tool waar je dit mee inzichtelijk kunt maken. Full garbage collect cycles moet je zo veel mogelijk proberen te vermijden in near real-time applicaties, de beste manier om dat te doen is om objecten zo kort mogelijk of zo lang mogelijk te laten leven. Klinkt vaag maar als je de output van CLR Profiler hebt gezien snap je het wel.