Ripping Apart Microsoft Visual C++: Performance

I said I'd do it and I never lie. Lets tear apart Visual Studio. For now I'll start with performance, not my favorite topic, but I'll get to the debugging features later. Each one of these entries deserves its own bog post, but who cares, you probably just think this is flame anyway (I think its thoughtful analysis!).

Performance
1) Starting Up (and Stability)
2) Loading DLL debug modules
3) Running a program

Performance
1) Starting Up
Normally I don't really care about program start up time. I use Visual Studio extensivly, once I start it up, I should never to start it up again. For me its a constant-order performance hit which should only effect me when I restart my computer. Most people restart the computer once a day, I do it much less. Waiting an extra ten seconds a day isn't a big deal.
However Visual Studio crashes. It crashes a lot. I find that halting in the wrong place, or stopping debugging at a key moment will cause it to crash. This happens about 4 to 5 times a day. Therefore 4 to 5 times a day I find myself restarting Visual Studio, loading my project, and pulling everything back into RAM. Altogether its probably a 45 second ordeal which is over three minutes a day. Not a biggie, but definitely an annoyance.

2) Loading DLL debug information
Why does visual studio have to load all of the debug information about a DLL the instant its loaded into program memory? It doesn't take long to load each DLL, probably about a quarter second. However most modern win32 apps link in about 5 to 15 DLLs (complicated programs much more). Most of the DLLs are loaded up at the beginning of program execution so there is a visible delay waiting for them when your program starts. That means I wait two to three seconds every time I want to run a program, even if its a simple console app. If I run the console app alone it completes in a fraction of a second.

This is only a real problem with the CLR. I'm guessing that its a problem with JIT caching or something, but I'm not too sure.

3) Program Performance
A good debugger should be as passive as possible. However running a program within visual studio is significantly slower then running it standalone. I'm not too sure why but I'm guessing that my item above plays a large roal. It could also be that Visual Studio installs all sorts of exception handlers and instrumentation to get things working. With managed CLR Visual Studio may be doing much much more. But its all really speculation.