MSDN Magazine - March 2008 - (Page 17)

System Assemblies and Other Processes Once you have eliminated the loading of all unnecessary assemblies at startup (for further improvement, you can also modify the application code to delay some of the initialization work done at startup), the next thing to do is to reduce the amount of code that is loaded from system assemblies. Unfortunately, I know of no tools that can tell you how much code is pulled in if a system API is used. That would be very useful because the developer could use APIs in startup code that need less code to be loaded from the system assemblies. Until such tools become available, you can get an approximate page cost of an API by using an instrumentation-based profiler (for instance, the Visual Studio® Performance Tools). By looking at the profile data, you can try to avoid APIs that involve system calls with big call trees (big tree, deep-nested calls mean that the code for each method call was pulled out from disk—therefore, it is a way to approximate how expensive the call is). If you can implement the same functionality by calling an API that doesn’t have a deep system call tree, you will save time. This is not a scientific approach because it is not easy to determine how much code can be saved by cutting a call tree, but it generally makes sense that the bigger the call tree is, the greater the amount of code loaded from disk will be. In some cases, your application explicitly or implicitly might launch other processes at startup. You can easily find out what they are by using the –o option in the Windows debugger (windbg). The –o option causes the debugger to attach to any child process. A typical example of a process being launched implicitly by the application occurs when the app uses XML serialization and doesn’t precompile the serialization classes (using the Sgen utility). When this happens, the C# compiler is launched to compile them. Launching other processes is usually a very expensive operation that can have a significant impact on startup. NGen Performance Native image generation (NGen) always helps improve warm startup because it avoids the cost of JITing code. NGen can also help in cold startup scenarios if mscorjit.dll does not need to be loaded because all code used by the application is already precompiled using NGen. If only one of the modules does not have a corresponding native image, however, the mscorjit.dll will still be loaded. Then not only will the code will be JITed, consuming CPU cycles, but also many pages in the NGen images will be touched because the JIT compiler needs to read metadata. This will result in an even worse startup. For this reason, it is recommended that you remove any code that might cause JITing during startup. Of Once you have eliminated the loading of all unnecessary assemblies at startup, the next thing to do is to reduce the amount of code that is loaded from system assemblies. CLR Inside Out march2008 17 http://www.iocomp.com http://www.iocomp.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.