With the upcoming Visual Studio 2010 Release Candidate around the corner, I would like to talk briefly about some changes we have made to the first-launch-after-installation sequence. Many of you may notice that the first time you start VS after installing, once you have selected a profile, it takes a long time for the main VS window to appear, especially when compared to the Beta2 release last October. I want to make sure users are aware of what is going on here. Let’s talk about the changes we’ve made and the benefit these will have on Visual Studio performance and memory usage.

The longer load time is due to increased caching of key resources at first launch, which we expect to improve the overall performance of Visual Studio. Many subsystems in VS extract data from the 70+ packages which ship in the box and cache critical information in the registry or on disk. Examples of this include profile import, fonts and colors information, and the toolbox. Unfortunately, these caches are often very expensive to create the first time, and involve loading a large number of binaries into memory. As such, users were exposed to unexpected slowdowns and spikes in memory while using VS. As of Beta2, the timing of these spikes has also been unpredictable, as many of the caches were created asynchronously after startup in response to timer events, or loaded on demand in response to a user action (e.g. loading the Tools->Options->Fonts and Colors page).

To solve this problem, we have consolidated all the common operations which enumerate packages into a single step, and run that step out-of-proc during first launch. Once you launch Visual Studio and select a profile from the “Choose Environment Settings” dialog, we delegate all the heavy lifting to a second process, which resolves the profile completely, and creates critical caches for fonts, colors, toolbox items, and Microsoft Extensibility Framework (MEF) types. Once the helper process completes its work, we proceed to display the main user interface.

This design has a number of benefits:

1. By loading all the packages in a separate process which we then terminate, the memory footprint for VS on first launch is reduced significantly as we no longer hold unnecessary packages in memory.

2. By consolidating all the cache-construction into a single step, we eliminate redundant loading of packages to extract data for the various caches.

3. By pre-loading all the cache data, some traditionally slow user operations have been sped up dramatically (e.g. bringing up the Tools->Options->Fonts and Colors page the first time).

However, all the extra work being done at startup, plus the overhead of an extra process, does mean a longer first boot time for VS. Still, no better time to get that cup of coffee, right?

Sasha Siddhartha – Development Lead, Visual Studio Shell Team Short Bio: I started at Microsoft in 2003 and have worked on the Visual Studio Shell since 2008. Prior to that, I have worked in a number of areas across Microsoft, including Microsoft Business Solutions, Windows, and Windows Live.