MSDN Magazine - March 2008 - (Page 15)

Improving Application Startup Performance CLAUDIO CALDATO A s waiting for an application to start is frustrating to many users, focusing on your client application’s startup performance can greatly enhance your customers’ first and lasting impressions of your handiwork. And because startup performance matters to users, it’s worth exploring the factors that impact it so you can avoid the most common mistakes. Application startups are typically classified as either cold or warm. In the context of a managed application, cold startup is when neither the Microsoft® .NET Framework system assemblies nor the application’s code are in memory, so they all need to be fetched from disk. Warm startup is either a subsequent startup of an application or an application startup when most of the system code is already in memory because it was used previously by another managed application. Cold Startup In most cases, cold startup is I/O bound. In other words, more time is spent waiting for data than is spent processing instructions. The time it takes to launch the application is equal to the time it takes the OS to fetch code from disk plus the time it takes to perform additional processing such as JITing the IL code and any other initialization that is performed in the startup path of the application. Since processing is usually not the bottleneck in a cold startup, the initial goal of any application startup performance investigation is to reduce disk access by reducing the amount of code that is loaded. The way in which the application’s code is written also has a significant impact on cold startup so it is important to find out if, for example, the application opens additional files or launches other processes that could compete for I/O resources at startup. Because cold startup is an I/O bound scenario, the use of a traditional CPU profiler (whether instrumentation-based or sampling-based) will not help investigations significantly. Instrumentation-based profilers will report the time spent waiting on I/O as blocked time. The problem is that, even if you are able to attribute the blocked time to a specific call stack, blocked time is counted only once. Any following disk I/O is not taken into account, resulting in a partial picture of the actual contribution of disk I/O to the total execution time. With sampling-based profilers, the information collected can even be misleading. Here CPU usage, not I/O, is tracked, so all the time spend in I/O is not accounted for in the profiler’s reports. Figure 1 Time Reading Disk and CPU Time in Cold Startup Figure 2 Shorter Times in Warm Startup You can see for yourself in Figure 1 that cold startup is I/O-bound by launching your application twice in a row. The first launch will likely be much slower than the second (where most of the code needed for the execution is already in memory due to the first launch, saving time by avoiding disk access). Of course, to make sure the first launch is indeed a cold startup, restart your machine before and make sure there are no managed applications in the startup folder and that no Windows® service using managed code runs when the user logs on. Note that to perform an ideal test of cold startup, you should disable the SuperFetch service, which may otherwise preload some of the code needed by your app, creating a warmer startup scenario. The benefit of measuring with SuperFetch turned off is that you can count on the fact that all the code needed by the application was loaded into memory on application startup, and hence you can more accurately measure the cost of I/O. You should keep in mind, however, that what you are measuring is not necessarily the actual march2008 15

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.