Board index » delphi » Re: Is there a .NET compiler ?
Shawn B.
 Delphi Developer |
Re: Is there a .NET compiler ?2006-03-26 04:12:58 PM delphi45 QuoteHow much of a difference have you found it makes to performance when using specific optimizations. Second, ASP.NET does not accept NGEN'd images (the web application DLL and the assemblies in the /bin directory). This means that regardless if the image is NGEN'd, ASP.NET will JIT every first time the web application starts. Microsoft recommends only components that reside in GAC should be NGEN'd and only if they will be used/referenced frequently (meaning they are heavily reused components). Ultimately, it is only the start time that will be increased and you might be cheating yourself because the JIT during runtime can still make better decisions even though JIT uses NGEN during runtime. For .NET 1.1, there was some improvement overall, especially in the services and utilities area. But for the Web Application, you can not tell the different on the development computers but during production you notice the difference. The benefit, once again, is only seen by the first person to access the functionality. With .NET 2.0, things change. NGEN is amazing the and the difference is not only measurable, but noticable as well. Measurable, in my definition, simply means that a profiler is more likely to report the difference than the human eye. Noticable means the eye can see the difference. QuoteIs the difference comparable for all 200+ assemblies or do some benefit assemblies, but they are used in different places by different applications, certianly not all of them are used by one application. When there are fewer references, you won't notice it. On applications, such as our services and B2B applications, it is makes a bigger difference. ASP.NET will JIT (everytime) the web application and the private assemblies. ASP.NET will only honor the NGEN'd GAC components. When the majority of them are in GAC and NGEN'd, the only performance difference we notice is the startup time of the application, beyond that, you won't get any better performance from NGEN. .NET 2.0 has a much better NGEN. Combined with setting the assembly base address for the critical and larger assemblies, startup time flies. You might want to write a simple program to iterate through all the DLL's expected to be active during a typical application session (in our case, the services and web application servers) and locate base addresses that aren't used frequently. you will have to examine after several reboots to get a decent sampling. This program should be able to analyze the information and recommend a good base address. Why? Because noticably, in our case, when every assembly has to be rebased by Windows it slows the loading down. When it is properly rebased Windows doesn't have to do anything computationally during the startup/linking phase. QuoteHave you found any other advantages to taking this approach? actually started doing this for development boxes and it helps but not nearly as much as when we do it on the servers. To be honest, the first time in, you will wait 8 seconds or so on our main web applications or services, after that, it flies. NGEN'ing cuts it down (on .NET 2.0) to nearly instant. On 1.x, perhaps about 5 seconds, since the majority if it is the web app itself and not the dependancies. Microsoft states that only some of the core .NET assemblies are NGEN'd. I'd guess that it would be mscoree.dll and perhaps something like system.dll, system.web.dll, and a few other key ones. I have not tried this for standalone desktop applications. You should NGEN, as I said, only on the machine it'll be executed on, not NGEN'd then deployed. Also, NGEN'ing takes longer than the JIT when not NGEN'd. So if you deploy an assembly then NGEN while the server is active, you aren't helping matters unless you reboot later on or something. Long winded... sorry. The bottom line, we NGEN all our core assemblies, those that reside in GAC and ignore the private assemblies. The only benefit is the initial startup time of the service and beyond that NGEN doesn't make a difference vs. JIT. Properly basing our assembly address helped significantly better than NGEN did but combining all the techniques helps alot. When I earlier said it works well, I am only referring to the startup time since that is the only aspect of NGEN you can measure. I don't have a standalone app to test with since I don't write standalone apps, nor do we have any in our company. Everything is server-based. So things really only start once in a blue moon. On the dev server boxes and staging servers, more frequently and yes, NGEN makes a difference. 8 seconds vs 1/2 second or so for .NET 2.0... and 8 seconds to 5 for .NET 1.x. Thanks, Shawn |