When we last discussed performance, Microsoft's Larry Sullivan was stressing the importance of PerfWatson in generating reviewable performance data that would allow the Visual Studio team to make improvements. Sullivan is now able to reveal what his team has been able to do with that data and the specific changes being made to VS 11.
Virtual Memory
Sullivan begins by discussing the team's approach to Visual Studio's memory needs. Rather than convert the program to a native 64-bit application to access more memory, they decided to focus on being more efficient with the memory already available to them as a 32-bit process. Thus the team started with the largest consumer of memory in VS, DLLs. This led to an examination of over 800 DLLs for inefficiencies and excessive memory usage.
The next biggest memory consumer was the native heaps used by the various components in VS. Beyond reducing memory usage, the conservation effort also discovered "... hundreds of opportunities and were able to open “shovel ready” bugs for feature teams to fix."
The end result was that "roughly 300 fewer DLLs [were] being loaded and nearly 400MB of VM savings when loading a Web solution within Visual Studio". Performance gains for other solution types was not provided directly, although Sullivan did reply in a follow-up comment that:
I was able to get hold of the folks that had the numbers at their fingertips. In Beta VM is virtually flat for C++, but we do have wins coming in post Beta. There are working set wins in Beta of roughly 35 MB which is roughly a 12% improvement. We continue to work to improve Visual Studio 11 for the C++ developer.
Improved Solution Load Times
Solution load times affect all VS users, and the team has addressed this by introducing asynchronous solution loading. Nathan Halstead from Microsoft's Visual Studio Pro Team provided information on this approach which executes a project load in two phases, Modal Loading and Background Loading.
In the Modal Loading phase, VS11 loads the projects which it anticipates will be needed by the user, based on the open files in the last session. If the opened projects have dependencies to other projects, they will also be scheduled for loading in this phase. Non-critical projects will be scheduled to be loaded in the background phase.
The Background Loading phase unblocks the UI thread and begins background processing of the remaining load tasks. If the user's actions present a need for an unloaded project, VS will move that loading process to the forefront before continuing the background loads.
Compile-Edit-Debug Loop
Finally, Tim Wagner from the Visual Studio Ultimate Team described the changes made to the routine "compile-edit-debug" cycle. Wagner comments that the VS released at //BUILD was intended to be functionally complete while performance was going to be targeted for improvement by the VS 11 Beta release. Unfortunately Wagner's comments focus on the performance of Metro app development on Windows 8, which represents VS11-specific functionality that prevents comparisons to previous versions of Visual Studio.
Ayman Shoukry, Lead Program Manager at Microsoft, provides some hints on C++ performance, stating:
On the VC++ compiler & linker side, we have multiple improvements especially multithreading the compiler for Dev11. As a result we have seen large compile time improvements when building some of the large internal MS products. We will follow up with a more detailed blog about build time improvements in Dev11 VC++.
While these improvements have not been disclosed yet, Wagner did have a promising follow up:
Reporting on our progress here doesn’t mean we’re satisfied with performance in Beta – we intend to keep pushing for as many perf wins as we can get in Dev 11.
