The official source of product insight from the Visual Studio Engineering Team
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?
wouldn't it be possible to initiate a lot of these caching operations concurrently/asynchronously? I'd imagine something akin to loading windows services (whose definitions include dependencies). Especially with multi-core, this could be significant... additionally, cache not relevant for the UI wouldn't need to block the VS window.
Why not do it as a part of the installation? Ask for the profile selection during the interactive part of setup, and do the configuration at the end of the setup process. Delaying access to the app when the user expects to get to it (after first launch) isn't a good experience. We already went through a time-consuming setup process, why subject to another time-consuming configuration process again? Why not consolidate the two? At least do so as an option?
why not make this part of the setup?
me thinks it should be done at setup too.
Similar concepts from splash screen could be taken. http://blogs.msdn.com/visualstudio/archive/2009/11/11/behind-the-scenes-splash-screen.aspx
@Greisha has an excellent point out there.
If you think this should have been done at setup, you have a good point, and it may be something to consider as an option in next VS version.
I wasn't been involved in this design, but I suspect this was not done at setup in VS10 because the change would have been too big, and would have required cross-team collaboration and changes; usually such changes require a process called DCR, which I'm not sure if it would have gotten the approval during RC timeframe. (And then there is also the crowd that say setup time takes too long - adding more to it is also not the best solution).
Anyway, someone who installs VS and launches it, I don't think it would have seen a difference in the time he has to wait until he can actually write the first line of code. He'd still have to wait for the time to build those caches, whether it's done at setup time or at first launch. It's just a matter of perception - those who noticed the longer times in the first launch probably would have noticed the longer setup time. (Where it makes a difference is if you have a network administrator who installs VS for you :-) ).
Note that even in Beta2 there was a non-neglijible time you'd have to wait on the first launch to build the selected profile, and it has been like this since at least VS2002. Whether this should be done at first launch or at setup, this sounds to me like a different issue from what Sasha presented here.
As for the goal of the change, as Sasha presented it (consolidating the cache building to remove the crashed and memory spikes caused by loading lots of packages while building the caches on demand), I think this has been reached.
As a personal option, I also like the cache consolidation idea: the first time you open the Toolbox, you don't have to wait for its cache to be constructed. Now it's ready to be used immediately...
Alin Constantin
[VSP development]
one of the reasons it's done during the first execution, is because the settings are per user/login account... for this to occur during setup would mean that the account performing setup (which may be administrators instead of developers) would be making the choice for ALL of the systems' users.
As I said before, being able to run some of the caching concurrently (fonts, toolbox, MEF) would seem to offer more benefit... additionally, if some components (like the toolbox) aren't necessary until a project is loaded... I don't see a need to block the IDE while the winforms buttons load into cache.
Aside from my comments, I'm glad to see any and all improvements to the VS load time :)
I think the idea to put the caching into a separate process in order to reclaim the memory is great.
Based on what you described about the old method, namely loading a minimal cache and then waiting for user requests, it IS possible to run VS with a minimal cache prepared.
If so, why must VS wait for the external process to complete the creation of all caches, why can't it wait for the time required to build the minimal crash, let the external process continue, and in the meantime display the UI?
I have a feeling this has something to do with 'what if the user tries to access one of the caches still being built?', but I was wondering if you had an answer of your own?
Thanks everyone for the feedback!
To answer a few specific questions:
1) Why not do this at setup?
As Scott and Alin have mentioned, most of the caches are profile-specific, and profiles are a per-user concept. There is no guarantee that the admin who initiates the VS install is the same user who launches the app - in many enterprise scenarios, we expect the exact opposite.
2) Why block the UI while caches are building? Why not load the minimum profile and then show UI?
The main reason is that we explicitly want to minimize the situations where a user starts interacting with the UI and ends up requesting a cache which hasnt been built. Currently, if we hit such a scenario, we would end up blocking the UI anyway, which we feel is more annoying when the user is actively working with the IDE.
A secondary reason is to minimize the risk associated with this change for Dev10. Even in previous releases, it was always possible to "short-circuit" the first-launch sequence by simply starting another VS instance while the first one was loading the profile. However, there were subtle problems that could arise from starting the second instance while profile import is in progress. Now that we are doing profile import on a separate process, we ran the risk of getting into this problem state all the time, if we didnt block until the caches were all in a good state.
3) Can we build the caches concurrently?
This is an area we can try to optimize in a future release but, for Dev10, our goal was to optimize the product's memory usage while minimizing code change.
Good post .
I am still waiting for the RC of VS 2010