Question

I'm trying to profile the startup time of my application, so I wrote a small C# program that will start my application using the Process.Start() method, and time it using a stopwatch.

When I try to start the application myself (by just clicking on it), it probably takes 2-3 seconds. When I try to start the application using my test program, it takes 8-10 seconds. The startup time consistently differs in that magnitude.

Any idea why using Process.Start to start an executable would affect startup times so much?

Was it helpful?

Solution

Thanks for all your help. I have the answer, and it's unrelated to Process.Start.

After I start the process, I was waiting for a specific window handle to appear to know that the app actually showed up. The loop was too tight. I introduced a 200 ms sleep in the while loop, and startup time was normal again.

OTHER TIPS

Your clue should be that Process.Start() is in the System.Diagnostics namespace. When you start a process in this manner, you're attaching a bunch of monitors/inspectors to it. This definitely adds an overhead.

You might want to try immediately calling Dispose() on the Process object after you start it (in order to avoid unnecessarily-prolonged process monitoring), but you will not be able to completely avoid the associated overheads.

Simply put, you are starting actually two process's not just one. That's why it takes longer.

When you double click on your app, you are loading just one application and all it's DLL's.

When you run your diagnostic app, you first are loading the first application with it's .NET assemblies which have to be JIT'd (Just in time compilation: which is not free). Only then after that is all done, then the OTHER application gets to start. If your target app is also a .NET app, then the whole cycle repeats itself.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top