Devenv /Setup Performance


When starting out with the Visual Studio SDK, one of the things you may notice from the start is the time that it takes to build many of the samples. It’s not the actual C# or C++ compilation that takes so long, but rather a post-build step that is run: “devenv /rootsuffix Exp /setup”. (The /rootsuffix Exp part simply says use the Experimental hive when running /setup.)

But why does the /setup take so long?

Setup essentially “resets” the IDE, taking into account any new packages that have been registered. Most of the steps in this process are on the order of fractions of a second. In Visual Studio 2005, a change was made in the way that project templates work which caused the /setup to increase dramatically. Starting with VS 2005, project and item templates are installed as .zip files. When you run /setup, a caching process happens, and part of that process is extracting every zip template on the machine. This doesn’t just mean community templates you may have installed off the Internet. This also includes VB/C#/C++ project and item templates. This is the portion of the /setup process that can cause it to take 60 seconds or more on some machines.

So what is Microsoft doing about it?

Unfortunately, for Visual Studio 2005, this problem will not be fixed. However, we are addressing it for Visual Studio 2008. Starting with Visual Studio 2008 Beta 2 + VSSDK, you’ll notice that the build time for almost all samples (and your own packages) is significantly improved. This is due to a new switch in VS 2008 called /nosetupvstemplates. In the VSSDK targets file, we will check if you have any ZipProject/ZipItem items in your project. These are the build items you typically will use when creating templates. If you don’t have any templates in your project, we will add the /nosetupvstemplates flag to “devenv /setup” which causes the template caching process to be skipped. This will take the build time for most samples down to only a few seconds.

If you do have project templates in your project that need to be built, the VSSDK targets will still run the full “devenv /setup” when your templates have changed from the last build.

Comments (4)

  1. dimaka says:

    Hi Aaron,

    Sounds very good! I would also like to offer a few comments related to “long /setup” issue.

    First of all, there are two situations when that issue is important. The first one is what you mentioned above (related to compilation time for VSX projects). The solution you are talking about is good enough for this case. But there is also a second situation which is not covered (or not completely covered) by adding a new command line option ‘/nosetupvstemplates’. I am talking about package installation on end-user machine. Of course, this will be essential only if the package includes item/project templates. Actually, all new language integrations do include them. In this case we are still having “long /setup” issue. And the end-user will be frustrated with a to-o-o-o-o lo-o-o-o-o-o-ong installation time for the package sized just a few megabytes.

    From my point of view, the “silver bullet” for all of those situations – either compilation time or install time – will be as named “delayed setup”. What do I mean? I mean there should be an option (/delaysetup or something similar), which tells Visual Studio to do all its setup routine when it is first run – not immediately.

    Benefits for “delayed setup”. It is fast – for both compilation and install time – even when package adds templates. Initialization will occur when it is really needed – on first run after calling with ‘/delaysetup’ parameter.

    That would be great if you kindly considered that!

    Thank,

    ~ Dmitry Pavlov

  2. Björn says:

    My naive solution to the template setup performance issue would be to compare the sources modification date to either the cached ones or some last run date (maybe per template in some sort of repository) and only perform the caching process for changed/not in the cache templates. Implementing and testing this would be a bit more expensive, though.

  3. dimaka says:

    +1 with Björn: from my point of view more intelligent caching logic makes sense as well.

  4. kinokijuf says:

    @Dmitry Pavlov: this wouldn't work if the user isn't an administrator. So it must be done during installation.