Visual Studio Performance Advice

People often ask about how to make things go faster in Visual Studio, the mojoPortal solution is very large and it can be very time consuming to rebuild all of the projects especially if your development machine is not very powerful. Visual Studio is a resource hog and really requires a pretty powerful machine, when you factor in that developer time is very valuable it makes a lot of sense to get the most powerful machine you can afford to make best use of your developer(s) time. But in the final analysis you must work as well as you can with the machine you have, so this article will suggest some ways of working in Visual Studio more efficiently.

1. Use The Debugger Only When You Need It

Often I see developers running their web projects in the debugger for no reason at all and this is the slowest way to work. The debugger is a tool for stepping through the source code at runtime to find out what is happening vs what you expect to be happening. If something isn't working right you should set break points in your code and then step through it with the debugger to learn what is happening. But this is not how you should work normally, only when you need to actually step through the code. Once you have built the entire solution at least once, then to run the project all you need to do is right click the Default.aspx page in the root of the mojoPortal.Web project and choose "View in Browser". This will launch the site in the Web server but without running the debugger and it will be much faster than running in the debugger.

2. Only Build What You Need To Build

Assuming you are working on custom features that are in your own projects, when you make a change you do need to build your project(s) again both to compile your changes and to run the post build event which copies your modified files up to the mojoPortal.Web project. But you don't need to rebuild the entire solution. You should not be modifying the mojoPortal code, all your work should be in your own projects so it should rarely be needed to rebuild the other projects after they have been compiled/built at least once.  And as mentioned above you don't need to run the debugger unless you have a need to step through the code, so your workflow should generally be to build your project since it has changes then just refresh the page in the browser, no need to launch the debugger.

3. A Web.config Optimization Which Helps with Slower Machines

There is an optimization you can make on the <compilation section in Web.config to speed things up as discussed in this blog post by David Ebbo, you can add the attribute optimizeCompilations="true". We have this information in comments in the mojoPortal Web.config file. I find it works well in general but occasionally I have encountered unexpected behaviors with this enabled so we don't have it enabled by default. But you can try it and it should help, if you encounter any problems try removing it and then put it back after the problem is resolved.

Created 2011--8-15 by Joe Audette