Visual Studio to Finally Address Performance Issues

Posted by Jonathan Allen on Sep 10, 2007

Sections

Development,

Architecture & Design

Topics

Performance & Scalability ,

.NET ,

Artifacts & Tools

Tags

Visual Studio ,

Visual Basic.NET

Visual Studio has been plagued with performance issues that have been getting worse with each version. These problems rarely occur in small projects but can have a dramatic impact on solutions with multiple projects or even a single, very large project.

In a Channel 9 video, Cameron McColl apologized for Microsoft not thoroughly testing Visual Studio with large solutions. He then discusses some of the specific performance problems and how they were addressed in VS 2008.

The first issue he covers is that of stepping through code. As many .Net developers know, there can be a 5 to 10 second lag time between each line of code. While this doesn't occur all the time, it can be quite frustrating when it does. He does not go into detail, but he does mention that in addition to the "crazy stuff" that they were doing, they had also stumbled onto an OS bug that added an extra second per step. This fix is supposed to be part of VS 2005 Server Pack 1 as well as VS 2008.

The next issue he discusses is how Visual Studio can suddenly freeze for a number of seconds as someone is typing. This has a number of causes, several of which have been fixed. One cause is the number of items in the task list, which includes errors, warnings, and 'to-do' items. Whenever the task list was updated, it refreshed each item by removing and re-adding it. This involved an expensive calculation involving the position of the scroll bar.

Another fix involves VB's background compiler. The background compiler gives Visual Basic a much richer design time experience with features like up to the minute code completion and error detection. Languages like C# and VC++ do not have this, so often the developer has to rebuild the project just to get a clear picture of the application's state.

A downside of this is that Visual Studio, while opening a solution, would wait until the background complier had a chance to run. This delay was particularly bad with larger projects. As part of this fix, the class and method drop-down lists above the code editor will now indicate when they are not ready.

Another much-needed change is that Visual Studio will now allow developers to cancel out of long-running operations. If a certain action requires information from the background compiler, the IDE will only wait to seconds before displaying a progress bar and cancel button.

The next fix is for scenarios wherein there is a significant delay when trying to edit an aspx file in a large web application. Like with the code editor, this was due to the IDE waiting for the background compiler. Now the editor starts working immediately, with the tradeoff that code coloring and completion is not available until the background compiler catches up.

The final fix he mentioned deals with compiling. For a solution in VS 2005 with 25 projects and approximately 3,000 files, a Rebuild All would take about 45 minutes. In VS 2008, that is down to one minute. Why? Because if a project was referenced by N other projects, it would be completely cleaned and rebuilt N+1 times.

1. Back to top

   Ha! try Eclipse esp w/ McAfee running...

   by Jim Leonardo

   While I'll admit, getting rid of some of these whacko performance bugs is a good thing, they seem minor compared to trying to run Eclipse with a virus checker also alive on the system. Just adding a new file to a fairly empty project can take an eternity in Eclipse with McAfee around. (And that's required by the corp, so I can't do anything about it)
   
   Jim

   Reply

2. Back to top

   Re: Ha! try Eclipse esp w/ McAfee running...

   by Jonathan Allen

   I don't think it is useful to say "We don't suck as much as they do.", especially when I have a deadline and VS has locked up for the 12th time today.

   Reply

3. Back to top

   Increase VisualStudio compilation time

   by Patrick Smacchia

   A few weeks ago I wrote a blog post on how to improve VisualStudio compiler perf:
   codebetter.com/blogs/patricksmacchia/archive/20...
   Personally, I'm working on a 50.000 C# lines of code application and I never wait more than 5 seconds for recompilation (on a descent machine).
   
   Patrick

   Reply

• Older >