Question

I’m using C++/CLI on Windows. It’s an MFC app built with /clr.

I want to test how long it takes my application to start up. The first time it took 10s, but subsequently it took 4s, 4s, 5s. I’m assuming this is due to Windows caching the DLLs.

Is there some tool that will allow me to remove a directory from the cache, so that my test conditions are the same each time? I don’t want to have to reboot between tests 🙂

Answer 1

If you’re using the .Net framework, chances are those 6 seconds are waiting for the framework to initialize (load mscoree.dll, etc.). CLR Inside Out: Improving Application Startup Performance is an article that was written for the MSDN magazine.

A cold startup needs to load all of the .Net Framework as well as run the JIT compiler to generate the code.

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.

When you launch the application a second time, almost all of that is done. i.e. The DLLs were loaded, it may pull the code that was previously compiled, etc.

The best thing you can do to decrease your startup time is to reduce the amount of .Net framework calls before your first window shows (since all of that will need to be compiled before it can run) and reduce the amount of disk I/O needed to launch your program.

Once your program is up and running, any uncompiled IL from .Net will be compiled by the JIT compiler when it is first called.

Also, as far as I know, once the Framework is loaded, there isn’t an easy way to unload it without rebooting (if you can unload it at all). Having a virtual machine in a saved state just before loading the Framework could drastically reduce the time needed for “reboots”.