CLR comprehensive and thorough parsing: improving application startup performance

Because waiting for an application to start is a frustrating thing for many users, focusing on improving the startup performance of client applications will greatly enhance the customer's first impression and impress them on the results of your efforts. At the same time, since startup performance is important to the user, it is worth studying its impact factors to avoid the most common errors.

Application startup is usually divided into cold start and hot boot. In a managed application environment, cold start means that the Microsoft®.net Framework system assembly and application code are not in memory, and therefore need to be extracted from disk. Hot start is a subsequent startup of an application, or an application that is already in memory when most of the system code has been used by another managed application.

Cold start

In most cases, cold start is limited by I/O. In other words, the time to wait for the data is longer than the time it takes to process the instruction. The time it takes to start an application equals the time it takes for the operating system to extract code from the disk and the total amount of time it takes to perform other processing, such as performing JIT on IL code, and any other initialization that is performed in the application startup path. Since processing is usually not a bottleneck for cold start, the initial goal of all application startup performance surveys is to reduce disk access by reducing the amount of code that is loaded.

The method of writing application code also has an important effect on cold start, so it is important to be aware of the following situations, such as whether the application opens other files at startup or other processes that may compete for I/O resources.

Because cold booting is a case of I/O restrictions, using a traditional CPU analyzer (whether based on instrumentation or sampling) does not significantly help the investigation. The instrumented parser reports the time it takes to wait I/O to block time. The problem is that even if you can attribute the blocking time to a particular call stack, the blocking time is counted only once. All subsequent disk I/O is ignored, resulting in a partial actual time of disk I/O as the total execution time.

When using a sampling based parser, the information gathered may even be misleading. It tracks CPU usage rather than I/O, so the total time spent in I/O is not recorded in the parser's report.

You can see it in Figure 1. Cold startup is subject to I/O restrictions due to two consecutive startup applications. The first boot is likely to be much slower than the second startup (at the second startup, most of the code needed to execute is already in memory because of the first boot, thus avoiding disk access and saving time). Of course, to make sure that the first boot is a real cold boot, you first need to restart your computer and make sure that there are no managed applications in the folder when the user logs on, and that Windows® services that are not using managed code are running.

Figure 1 Disk read time and CPU time in cold boot