Here's my list. All of these can be accessed on Tools -> Options menu:

1. Disable F1. (Environment -> Keyboard) This is probably the best advice that I found somewhere.
2. Disable "Animate environment tools" (Environment -> General).
3. Disable Start Page (Environment -> Startup).
4. Disable "Track Active Item in Solution Explorer" (Projects and Solutions).
5. Disable Navigation Bar (Text Editor -> C#). I think this is available for every language.
6. Set "AutoToolboxPopulate" to false (Windows Forms Designer).
7. You can set the Code view as the default view when viewing Windows Forms. Just right-click on the .cs file and select "Open With...".
8. Open Visual Studio using the command line (devenv) rather than using the Start menu. I don't know why, but I notice it loads faster.
9. Turn off Track Changes. (Text Editor->Track changes)

Basically I just customized John Lam's settings ^[1]. It's very minimal.

Last Resort:

• Reset all settings (Tools -> Import and Export Settings -> Reset All Settings)

Related articles:

• Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005 ^[2]
• Hard Drive Speed and Visual Studio Performance ^[3]
• Speed up Visual Studio 2005 ^[4] (link seems to be broken as of 2012-04-23)
• Optimize the launch of the Visual Studio 2005 ^[5] (link seems to be broken as of 2012-04-23)

@Orion Edwards:

I agree. Snippets are really a time saver. Actually there's a snippet editor that you can use, and I'm using it for a while now. You can find it at Snippet Editor ^[6].

I use keyboard macros (Ctrl + Shift + R) to get repetitive tasks done; you have to get the knack of it at first, but once you do, you can do a lot of stuff pretty quickly. For instance, you have:

DoStuff(1,2,"foo");
DoStuff(3,4,"bar");
DoStuff(123,123421,"baz");

... and so on for many lines, and you want to insert 'true' between the first and second arguments.

Put cursor at the start of the first line, then:

1. Ctrl + Shift + R [start recording]
2. Ctrl + F [open 'find' dialog]
3. , enter Esc [go to the next comma, close the find dialog]
4. type 'true,' [new text]
5. down, home [go to the start of the next line, so you're where you started]
6. Ctrl + Shift + R [stop recording]

Now you can just hit Ctrl + Shift + P many times, and it'll do that set of steps over and over again.

That's a simple example; you can do a lot of refactoring-like stuff pretty quickly this way, but it's also handy for wrangling big chunks of text for manual batch operations or whatever.

I'm sure if I learned how to do regular expression search/replace, I could do the same sorts of things that way, but I got into this habit from using Brief ^[1] a long while ago, and I've stuck with thinking about "doing tasks the way I do them by hand", rather than turning them into regular expressions.

(Presumably, refactoring tools could do that particular operation, but I'm in C++ and none of them work very well there.)

Other things:

• CommentReflower is a great add-in if you tend to write big chunks of comment; the original's here ^[2], and there's a Visual Studio 2008 port here ^[3].
• Ctrl + K Ctrl + F -> automatically re-indent code, useful when things have got messy.
• If you need to make the same change to a bunch of project settings, don't forget you can do find-and-replace-in-files on .vsproj files.

You can improve the speed at which Visual Studio starts up by using the '/nosplash' option. Bring up the Properties of your Visual Studio shortcut, change to the Shortcut tab and amend the Target field as follows:

"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe" /nosplash

One of the best enhancements I've found is to disable the onaccess scan of your anti-virus for the folder where your projects reside. Every time I did a build, the I/O activity caused by the virus checker decreased the speed.

I have a couple of recommendations regarding the build speed for Visual Studio 2008, related to the copying of files that occurs during the build.

Apart from the obvious recommendation of keeping the solution files small:

Defragment your hard drive

Disk performance is vital to the build speed. A daily, or at least, weekly defragmentation will facilitate this. If possible, schedule a nightly fragmentation to be performed automatically. Also, make sure you have plenty of room on the disk. The less space that is available, the fewer choises are available to the file system when deciding how to layout the files on the disk, and the faster the entropy on your disk will increase. Do you have several Source Control branches of your code checked out - why not delete the binaries from the old ones? You are likely to recompile them when you get back to working on those branches anyway.

Avoid Unnecessary File Replication

The standard setup for .NET solutions is that each assembly gets its own bin directory to which it is copied along with the assemblies of all its dependencies. If your solution contains an .EXE file and, say, 40 different assemblies. Does it really make sense to copy the dependencies of each assembly to each separate build directory? The target directory of the EXE should be enough. Another way to accomplish roughly the same would be to give the assemblies common output directories. That also avoids the copying. Some earlier versions of Visual Studio did not support this well, so be careful. I have, however, been using this approach with VS2008 for quite a while without noticing any problems.

Disable System Restore (Windows XP ONLY)

The implementation of System Restore in Windows XP actually creates backups of every DLL in the system every time they are modified. As compiling a .NET solution involves copying and overwriting many DLLs, this is assumed to impede performance. Windows Vista and Windows Server 2003 does not suffer from this problem. If you keep your source files on a separate logical drive, you can disable system restore for that particular drive and keep it enabled on your system disk.

Ensure 'Only build startup projects and dependencies on Run' is selected.

This option can be found under Tools -> Options... -> Projects and Solutions -> Build and Run.

For large solutions this can save a significant amount of time.

NB it's propbably best practice to avoid very large solutions, but if you are forced to work with one then this can make all the difference.

My experiences are more for C++ than C#, but here goes... I'm taking "Optimizations" in an ambiguous term on multiple views (code optimizations, IDE speed up, compilation speed up), but they are all specific to Visual Studio environment.

• For optimizations in code, have the compiler optimize by size rather than speed, not sure where I've heard this but someone once told me Microsoft compiles all their applications this way as well. Whether it is a myth or not, to me at least it makes sense (in most generic cases) because smaller code called often will have less cache miss. This is more for C++ than CLR based languages. Alternatively, if you know your target platform, you can probably target that rather than generic x86.
• For speeding up in Visual Studio, I've noticed that if I have break-points view showing, it keeps flashing, as if it is updating over and over, so I hide it. Perhaps it is just me (and psychological).
• For speeding up compilations, on one of the projects, it used to spew 1000+ warnings (it's a project mixed with C# and C++), and it used to take 20 minutes to compile (all the warnings was because of this ^[1]). The point here is, having a lot of messages serialized to output causes slowdown, so pay attention to first sign of your warnings and fix it. I'd also imagine that Visual Studio's "Error List" panel has to collect the Warnings and Errors into that view, which causes extra slowdown when you have large amount of warnings.
• Another speed-up for compilations, as somebody as mentioned, is Xoreax's IncrediBuild ^[2]. But they don't work on C# (yet), only on Managed/Unmanaged C++. I used to be skeptical about distributed compilation because of my experiences with distcc, but it was because all my PC's at home are different speed, a heterogeneous distribution. At work, because of the homogeneous structure where all have similar speed, it works better. Also, distributed computing is only useful when you have machines to distribute to (* grin *) Somebody also mentioned Visual Studio's parallel compiling option (if you have multi-processors, you've probably seen messages while compiling of "1> Compling Proj1", "2> Compiling Proj2" (or something like that), where Visual Studio will compile N projects (where N = number of processors you define in your options). Unlike IncrediBuild, VS distributes by projects rather than by files, and this is only useful if you have multiple projects in single .SLN.
• Another speed-up for compilations, some have mentioned increasing memory, although that would probably help, from my experiences, a faster drive is more beneficial than memory. I've seen 2 (similar performance) PC's compile the same exact projects side-by-side, one with faster drive than another, and the gain is significant. Bottlenecked on file I/O writing the .OBJ file or seeking for .cpp file, you get the picture. Back in the old-days, we used to output all the .OBJ files to RAM drives instead of hard-drives and that sped up a lot. But today, projects are probably too large to fit in a RAM drive or the performance of drive is so much better that it's not significant to do this.
• For speeding up in Visual Studio for debugging, if you don't need it, don't include the symbols from Microsoft ^[3] and you'll notice that your debugger loads faster into your applications.

I will edit/add more as I think of it.

Life Changing XAML Editing Tip

If you get annoyed at Visual Studio hanging for a few seconds when you try and edit XAML, using Life changing XAML tip for Visual Studio ^[1] will improve things no end. It works so well I don't really understand why it's not the default behaviour.

From my empirical testing, Visual Studio experiences an inverse linear relationship between UI responsiveness and number of projects "loaded". When I say "Visual Studio", I really mean "Visual Studio and ReSharper", because AFAIK most people work with ReSharper or a similar tool installed. I do not know if this slowdown is seen without ReSharper.

Reducing the project count is not always possible or desirable. However, unloading projects you are not currently working on mitigates the performance issue. BUT, doing so can break the build from with Visual Studio and/ or cause problems to be hidden when you make a change that affects an unloaded project.

THE SOLUTION: "unload" all projects you are not working on (or as many as is needed for performance to be tolerable) and perform builds from the command line, using the multi processor option.

This approach ensures Visual Studio remains responsive and useful, whilst at the same time a full compilation is performed.

This sounds like a very simple solution, and it is - but it can have a HUGE impact on productivity.

In summary - for large solutions use visual studio as a plain-old text editor and leave the compilation heavy lifting to MSBuild, invoked externally from the command line.

Empty your Recycle Bin ^[1].

Also: turn off HTML and CSS validation, making it easier to spot the actual errors in the Error list.

Under Tools -> Options -> Text Editor

• Turn off HTML validation: HTML -> Validation -> Untick 'Show errors'
• Turn off CSS validation: CSS -> Miscellaneous -> Untick 'Detect errors'.

(Use Firefox's HTML Validator instead, or similar)

I find that if you are using a solution with a ton of files, the detection for file changes slows things down, especially if you are editing files on a shared folder. This doesn't work as well if you use a command-line source control system, of course.

• Environment \ Documents \ "Detect when file is changed outside the environment"

Note that the same setting exists in almost all editors, and makes a big difference when editing files on a share.

This is not a Visual Studio enhancement, but Windows enhancement.

There is a tiny tool called KatMouse ^[1] that I cannot live without. KatMouse make any window or component scroll without focus, when mouse pointer is over it and mouse wheel is used. So you don`t have to click the window or component to set focus and then scroll, you can just point mouse over it and scroll.

Very useful for programmers of course!

However, this does not work in Visual Studio 2010 as they have a custom window management.

One thing that can speed things up significantly is turning off IntelliSense ^[1]. Of course that will probably slow you down. But at my office we use Visual Assist X ^[2], which albeit isn't free, but is better in a number of ways.

In any case, IntelliSense can't be disabled with a dialog box checkbox (as far as I know) but the process is pretty straightforward:

1. Close Visual Studio.
2. Remove the .ncb file next to the .sln file for any solution you work with.
3. Delete or rename the file C:\Program Files\Microsoft Visual Studio 9.0\VC\vcpackages\feacp.dll. (The 9.0 part of the path will be different for versions other than Visual Studio 2008.)
4. (optional) Install some IntelliSense alternative like Visual Assist X, or prepare to do a lot more typing.

This is not related to performance of the IDE (buying more RAM and an SSD ^[1] goes a long way towards that), but to the performance of you (that is, your personal productivity).

Learn about and use snippets, and the advanced text editor shortcuts.

Once you learn to use the snippets in E Text Editor ^[2] and TextMate ^[3], you'll never want to code without them, and Visual Studio 2005 and Visual Studio 2008 can support snippets.

Unfortunately, the Microsoft Snippet syntax is verbose and crappy (XML!), and there's no inbuilt-editor, you have to roll the .snippet XML files yourself and import them, but it's still well worth doing.

For example, I have a snippet, asnn, which expands to Debug.Assert( [object] != null );.

That alone has made it noticeably nicer to use.

I also have Ctrl+Shift+k bound to Edit.LineDelete and Shift+Enter bound to Edit.LineOpenBelow - mimicking E/Textmate. Those are awesome.

Increasing the speed of Visual Studio? Why not instead increase your efficiency with the tool instead?

I use ReSharper ^[1] at all times when programming in C#, and though it will slow down Visual Studio pretty bad, I still code way faster with it..

But I am very exited about the supposed performance gains in Visual Studio 2008 SP 1. Visual Studio 2008/2005 was an enormous performance boost, and I hope they can keep it up.

Try running your Windows machine using /3GB mode and making Visual Studio large address aware. Your IDE will have more RAM available to it and run much faster.

Refer to Hacking Visual Studio to use more than 2 gigabytes of memory ^[1] for reference and how-to.

If you are working with a team of developers, check out Incredibuild by Xoreax ^[1] (or as we used to refer to them, "Planet Xoreax"). It very seamlessly sets up distributed compilation in Visual Studio. I used this at a past place of employment and it cut our build times from 40 minutes down to around 7 minutes.

Getting Incredibuild set up truly changed the way I went about my work - I was actually able to get a streamlined code-compile-test cycle going.

Using tokens in Tools -> Options -> Environment -> Task List will slow things considerably when you have lots of instances of a token and a large number of files.

Also with a large number of VB.NET projects background compilation can be a dog so there was a hotfix ^[1] for Visual Studio 2005 that increased performance.

@ lomaxx ^[1]: There's a way to track the active item only on demand ^[2].

I like this for at least a couple of reasons. One is that, especially in a big solution, working for a while with "track active item" turned on results in a large portion of the project tree being expanded, and thus a little hard to navigate.

Something that has saved me a few seconds here and there is a macro I found a while back that allows you to attach to the aspnet_wp.exe process for debugging. This way the IDE doesn't launch a new browser/tab every time you hit run or F5. This can be annoying if you're deep within a project and launching at the project start up page isn't beneficial. There are probably other ways to do this but binding the 'AttachToWebServer' macro below to a keyboard shortcut has served me well.

Public Sub AttachToWebServer()

	Dim AspNetWp As String = "aspnet_wp.exe"
	Dim W3WP As String = "w3wp.exe"

	If Not (AttachToProcess(AspNetWp)) Then
		If Not AttachToProcess(W3WP) Then
			System.Windows.Forms.MessageBox.Show(String.Format("Process {0} or {1} Cannot Be Found", AspNetWp, W3WP), "Attach To Web Server Macro")
		End If
	End If

End Sub

Public Function AttachToProcess(ByVal ProcessName As String) As Boolean

	Dim Processes As EnvDTE.Processes = DTE.Debugger.LocalProcesses
	Dim Process As EnvDTE.Process
	Dim ProcessFound As Boolean = False

	For Each Process In Processes
		If (Process.Name.Substring(Process.Name.LastIndexOf("\") + 1) = ProcessName) Then
			Process.Attach()
			ProcessFound = True
		End If
	Next

	AttachToProcess = ProcessFound

End Function

Also, the code highlighting above is dieing on the backslash in the LastIndexOf method but the code is accurate, pasted directly from my macro editor.

If you are using Visual Studio 2008 then I recommend downloading the newly released SP1.

Among other things it is meant to increase the speed of switching to design view - see Faster switch to design view in VS 2008 SP1 RTM ^[1].

Other updates: Web Development Updates in Visual Studio 2008 SP1 ^[2].

Sitecore ^[3] warning: Don’t Install .NET 3.5 Service Pack 1 on Sitecore Servers Yet ^[4]

To avoid large delays when you run a large Windows Forms ^[1] program in the debugger. Close all Visual Forms Designer tabs, quit Visual Studio, then run Visual Studio again and load your project. Loading the Designer at all (even if you close it again) can cause these weird large delays when your program runs in the debugger.

How I found this out: I have a rather large C# Windows Forms solution with dozens of projects that used to take forever to run when I hit F5 - even if I made only small changes and recompiled. Initially I thought it was due to the size of the solution, but I later noticed that the compilation was finishing quickly, but there was a still delay before the main form would load.

Later I found the same strange delay on another, new, smaller project and realized what I had in common: the Designer. Now I do all my design work in batches, and then close any Designer windows, quit Visual Studio, re-launch Visual Studio, and go back to coding.

The main thing I've found is disabling the "Use Visual Studio hosting process" under Project Settings->Debugging for C# projects. This fixes the problem where (on some machines) Visual Studio will freeze up for 30+ seconds after a launched project terminates, instead of letting control return to the code editor immediately.

I'm a big fan of snippets; they really speed up the work. And as you all know, programmers are lazy even to type. :-)

Here are two snippet editors for VB.NET: for Visual Studio 2005 ^[1] and for Visual Studio 2008 ^[2]

And here is a very nice collection of snippets: for Visual Studio 2005 ^[3].

Have fun.

One of the best ways to speed up a computer doing almost anything is to install more memory. You pretty much can't go wrong with that.

Another little performance boost I remembered this morning:

If you don't need XML Documentation, you can turn it off by right clicking in your project in solution explorer, selecting Properties -> Compile tab and uncheck the "Generate XML Documentation File" option

If you're using the Visual Assist add-in and Visual Studio starts getting really slow and using a lot of RAM, you could try deleting the folder C:\Documents and Settings\\Local Settings\Application Data\VisualAssist\vs8.

I've had to do this twice in two years of using Visual Assist, and both times it's had a dramatic effect on my speed. Visual Assist now has to reparse everything, but it does that in the background, so it's not much of a penalty.

I'd recommend moving your Visual Studio solution to a RAM drive. That speeded up my Visual Studio (especially operations like "Find in files" are lightning fast).

I would recommend either the free Gavotte RAM disk ^[1] or commercial product from QSoft.

I used Gavotte (which is quite fine) and now I'm running on QSoft (it can automatically save and load your RAM drive content on shutdown/startup and/or defined time/time-intervals).

BTW. QSoft prices start from 12$ (much less than their competition).

NOTE: I'm not a related to QSoft other than just being a happy customer :)

In Visual Studio 2010 - disabling GPU acceleration can make a huge difference in editor response/sluggishness even with workstation-class graphics cards (like older Nvidia Quadros).

This is also true of Adobe Photoshop CS4 and later - it seems to me the "detection" isn't exactly smart enough to evaluate the actual performance of the GPU before enabling it ^^

If you are using Visual Studio 2008, you can compile using the /MP flag to build a single project in parallel. I have read that this is also an undocumented feature in Visual Studio 2005, but have never tried myself.

You can build multiple projects in parallel by using the /M<maxprojects> flag, but this is usually already set to the number of available cores on the machine.

EDIT: I'm sorry, this is only for VC++ I believe, I should have read more carefully.

The single biggest thing you can do to improve the speed of Visual Studio is to not use an integrated source code control system. All the checking it does to put the right icons in the solution tree takes FOREVER.

Disabling the splash screen seems (psychological?) to make Visual Studio load faster.

To disable it, modify the shortcut to "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe" -nosplash

A macro that replaces F1 with an open Firefox and Google for the selected word is nice too.

If you are using Windows Vista, change the theme to Windows standard, in short stop using the Aero ^[1] thing.

And I've observed on my system with Windows Vista business edition having 2 GB RAM on Core 2 Duo ^[2], that having Visual Studio, SQL Server Management Studio ^[3] and Outlook, all these three opened simultaneously had a major kick on performance.

If using Team Foundation Server ^[4], then keeping the Source control explorer always open in Visual Studio 2008 ^[5] too slows down Visual Studio. One can have a button to bring open the SCE window on a toolbar.

I suggest the reading of "Visual Studio Hacks" by James Avery. There are a lot of hint to better use your favorite IDE ;)

Snippet Designer On CodePlex ^[1]

It may help installing more memory, but I've already got 4 GB RAM in my machine. However, I read a post from Scott Guthrie ^[1], Tip/Trick: Hard Drive Speed and Visual Studio Performance ^[2] a while back that said he installed a solid state drive in his laptop and got a nice speed boost.

1. IncrediBuild ^[1] is really amazing stuff. In my case, it reduced compilation time from 30 min to 7 min and computer is not frozen so you can do some other things in parallel.
2. RAM disk if possible
3. If you have two HDDs, put the source code and swap file on different drives.

Use the magic C++ " Unity build ^[1]" technique... It's actually amazing: 20 min to 3 min minimum rebuild/link time for us.

Ctrl + R, E will encapsulate a field (you have to have your cursor on the field). It's somewhat redundant in Visual Studio 2008 where you can have automatic properties, but it's excellent for Visual Studio 2005.

A good list of Visual C++ tips is here: http://www.highprogrammer.com/alan/windev/visualstudio.html

Are you also referring to shortcut keys to speed up development time? If so, Alt + highlight with a left mouse click allows you to select a "box" of text. It is extremely useful.

Very useful batch (*.bat) file execution

Basically automating command line scripts execution. I usually write few database scripts that recreate the whole database of the project. These scripts are version controlled. I also use a batch file that runs all of these on my local database. Running this batch file within Visual Studio can easily be enabled by adding and additional editor for batch files.

Read the blog post Running batch files (*.bat) inside Visual Studio ^[1] where I explain the whole process step by step.

The very best optimization of all : Check for Visual Studio Updates

I wrote a smallish post, Increasing your project's build efficiency ^[1], on increasing the load time on a larger project that some might find interesting get.

A very obvious solution, but go to task manager and kill any processes that you don't need.

Here's my test: Standard build: 1.04 minutes "Only Build Startup and dependancies": 53 seconds build time "Selected projects only": 1.17 minutes build time "Killing unnessary processes": 4 seconds.

I'll repeat that; 1 min 4 seconds to 4 seconds by just killing processes you don't need! :)

A slightly philosophical answer, do less, KISS (Keep It Simple, Stupid)

Don't gold-plate your code, don't create a highly complex database driven framework if a simple class will do