If you’re developing on Windows, chances are you are using VS.NET. And if you’re using VS.NET, you’ll probably feel like the thing could go much faster. Well, it turns out it can - I spent a weekend researching how to do that, so here are the results for the startup process. (I’m taking 2005 only - YMMV for other versions)
To actually time the startup process, you can cause Visual Studio to write a log file - just specify /Log <logfile> at the command line. I’ve written a little Ruby script that actually does that for you, and measures the time taken for the startup.
When I started doing that, I just kept looking at the generated log file (which conveniently contains timing info) and considered the startup done once no new info showed up in the log file. That last line is the trigger point in the script. (Why so complicated? Because VS.NET still does stuff while it pretends it has started. Doesn’t help me, since it’s still not doing what I want it to do during that time)
Just running VS.NET “out of the box”, it takes on average 11.6 seconds to start up. (I’ve always tried it 10 times in a row and averaged, in case Windows file caching throws me a curveball).
Just by eyeballing, the biggest time eater seems to be the “Visual C++ Developer Center” start page. Let’s turn that off. (Tools/Options/Environment/General/Startup/Show empty Environment). And while I’m at it, let’s also turn off the download off content. Since I have VS2005, there has been about one interesting article on that page, so I’ll survive.
The surprising result: Visual Studio does not load the “Common IDE package” anymore - whatever that is. Startup time is now down to 2.4 seconds.
As a next step, I disable all the add-ins I don’t need. Some, you can just turn off via Tools/Add-In Manager(AMD Code Analyst). Others, you actually need to uninstall. (I’m looking at you, Solution Build Environment). That actually cut down the startup time to 2.0 seconds.
Next up - let’s get rid of the splash screen. Just start devenv with the /nosplash argument. It turns out that just feels faster, since you don’t have to stare at the startup screen. The startup time is still pretty much the same.
From here on out, we’re firmly in the realm of myth. I tested a few other suggestions, but none of them had a measurable effect on startup time. If you still want to try them, here they are:
Turning off animated windows: Tools/Options/Environment/General/Animate Environment. Might help later in the project, when you have many windows open.
Another frequently repeated tip is turning off dynamic help. That option is not available in VS2005 any more. However, the other tunings above seem to have accelerated the startup of the external help viewer a bit. I have no idea why, but I’ll certainly take the speedup.
Cleaning MRU lists. Not really helpful. It might bring an extremely slight improvement, but variations between individual VS runs are way bigger than that improvement. That particular myth seems to be a holdover from a VS2003 bug with the MRU