Visual studio is a pretty awesome IDE, but sometimes you just wish it would go faster. I was wondering if people have any tips or tricks to help speed up visual studio in day to day use.

Things that I'm particularly interested in are speeding up build times and switching aspx files from source to design view seem to bring it to a grinding halt.

Having said that, I'd be keen to hear anything that anyone uses to make VS run that little bit faster.

Edit: Merged answers from related question, covering VS2008SP1. Please include any optimisations specific to the latest IDE.

+5  A: 

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 -

other updates:

Sitecore warning: Don’t Install .NET 3.5 Service Pack 1 on Sitecore Servers Yet

Christian Hagelid
+275  A: 

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. It's very minimal.

Last Resort:

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

Related articles:

@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 here.

+1 for the F1 key remove! always wanted to change that. thx!
Peter Gfader
A new computer also really helps. The difference between my office computer and my personal is really big.
What about unload projects where possible. I sometimes have solutions with 10 to 15 projects in if I disable the ones I am not currently working on I get a good boost. Just have to remember to reload and build before any breaking changes to shared code.
A small wrinkle on disabling the start page: I find "Recent Projects" on the start page very useful, as hovering over a project name provides the full path to the project/solution in the status bar. Rather than disabling the start page, I clear the Start Page news channel. Still get snappy loading, plus useful info.
Dan Blanchard
Why F1 could slowdown VS? Why?? :-o
Isaac, I think the biggest problem with F1 (at least it is for me) is that it is too easy to press by mistake when you try to press escape, and it takes forever to load the help if you do happen to hit it by mistake.
Doug McClean
Once I was made to use a keyboard which had touch sensitive F1-F12 keys, but thats where I would rest my hands when not typing. So this would have been very helpful back then :-)
F1 speed problem in VS2010 is no longer relevant
Pierre-Alain Vigeant
+9  A: 

This is not related to performance of the IDE (buying more ram and an SSD goes a long way towards that), but to the performance of you (ie: your personal productivity).

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

Once you learn to use the snippets in e-texteditor and textmate, you'll never want to code without them, and VS 2005/8 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.

Orion Edwards
I think Shift+Delete is default bound to Edit.LineDelete
Re#er live templates works great.
Arnis L.
Nice idea, thanks! Optimized it by shortening the snippet to 'ass'.
Ctrl+Shift+l is also bound to Edit.LineDelete, I believe. Not sure why k would be better.
Doug McClean
Downvote because your perjorative characterisation of the OP is nothing to do with the question asked. Snippets and shortcuts are useful, but don't solve the problem specified and it's obvious you are aware of this. It seems to me you've just deliberately taken the opportunity to snark.
Tom W
@Tom W - WTF?!? It's not snarky at all, and It had nothing to do with the OP. My point was saying that you (the "general" you) can improve your productivity by using snippets/etc, but this isn't related to the performance (in terms of execution speed/memory usage/etc) of visual studio itself.
Orion Edwards
@Doug McClean - k is arbitrary, it just happens to be what I'm used to from the other editors I use
Orion Edwards
It's taken a couple of readings but I suppose I can see where I misunderstood your tone. Your point would have been a lot clearer if you'd started "This post is not related to...". I'm sure you can see how it would be easy to interpret as "You think visual studio is slow because you're slow, not because it is". Downvote rescinded.
Tom W
+4  A: 

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.

Ed Swangren
+7  A: 

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.

The How-To Geek
+11  A: 

Increasing the speed of Visual Studio?
Why not instead increase you efficiency with the tool instead?
I use ReSharper at all times when programming in C#, and though it will slow down VS pretty bad, I still code way faster with it..

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

Lars Mæhlum
Agree, for middle-size projects you'll need at least 2 GB or RAM. On my machine (Pentium D 3 GHz, 4GB RAM) ReSharper is not usable for files that have more that 2000 lines of code.
Michael Damatov
I can't for the life of me understand why anybody would want to cram 2k lines of code into a single file?
Lars Mæhlum
Resharper 4.5 will be out shortly, and the beta version is *much* faster than 4.1.
Yeah, too bad the beta version was a bit too buggy for my taste. Maybe there is a new one out?
Lars Mæhlum
ReSharper 4.5 is still too slow, and causes me to wait minutes while it updates it's cache and parses my files. But the productivity tradeoff is still positive, so I keep using it...
Alex Czarto

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

I'm open to either. Or anything that helps me increase productivity is a bonus. ReSharper is definitely high quality, although I have a fair few of the default features turned off because of the slow down.

+4  A: 

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 VS 2005 and for VS2008

and here is a very nice collection of snippets: for VS 2005.

Have fun

+3  A: 

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.

Greg Hewgill
+1 Works especially well when compiling, linking and doing all sorts of disc access. Having all your source, dependencies, intermediate and output files in memory cache is teh win.
Marcus Lindblom
+1  A: 

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.

I've got 4GB ram in my machine, however I read a post from ScottGu a while back that said he installed a solid state drive in his laptop and got a nice speed boost. I might have to dig that article up I think

edit: It's been dug up

+2  A: 

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

+40  A: 

I use keyboard macros (control-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:


... 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:

control-shift-R [start recording]
control-F [open 'find' dialog]
, enter esc [go to the next comma, close the find dialog]
type 'true,' [new text]
down, home [go to the start of the next line, so you're where you started]
control-shift-R [stop recording]

now you can just hit control-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 regexp search/replace, I could do the same sorts of things that way, but I got into this habit from using Brief 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 regexps.

(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, and there's a VS2008 port here.
  • control-K control-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.
Dan Mitchell
Downrated because it doesn't address the question at all.
Upvoted because it is very similar to the accepted answer. Recorded macros are really nice (didn't know VS has them and have been using notepad++ for that) but in this case, something like Eclipse's 'refactor method' is what you really want.

@Dan Mitchell: that reminds me of another great keyboard shortcut:

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

+4  A: 

To avoid large delays when you run a large WinForms program in the debugger, close all Visual Forms Designer tabs, quit Visual Studio, then run VS 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.

Has anyone else experienced this?

How I found this out: I have a rather large C# WinForms 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 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 VS, re-launch VS, and go back to coding.

Jared Updike
+6  A: 

If you are working with a team of developers, check out Incredibuild by Xoreax (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.

Matt Dillard
Note that the website says that this only works for C++ Visual Studio users.
+4  A: 

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 for VS2005 that increased performance.

Michael Prewecki
+8  A: 

One thing that can speed things up significantly is turning off IntelliSense. Of course that will probably slow you down. But at my office we use VisualAssist, 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 VS.
  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 VS2008.)
  4. (optional) Install some IntelliSense alternative like VisualAssist, or prepare to do a lot more typing.
Careful about this - We've deleted the .ncb file and replaced it with a .ncb folder (eliminating the ability to create intellisense files) and it has played havoc with the Windows Form Designers... especially when you have custom controls
i think NCBs are for C++ only
that was sweet :)
+3  A: 

@lomaxx: There's a way to track the active item only on demand.

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.

+33  A: 

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

Charles Anderson
Yay... finally i found this tip! Knew something like that existed, but couldn't remember.
Arnis L.
+18  A: 

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). 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. 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 and you'll notice that your debugger loads faster into your applications.

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

+1 for outputting .obj files to RAM. Haven't tried it yet, but it sounds like a genius idea
+2  A: 

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

+12  A: 

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.

Gareth D
Note that you can configure your own build configurations (on top of debug and release), I have one called 'work in progress' where I only rebuild the projects I know I'm working on.
+3  A: 

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.

Charles Anderson
+23  A: 

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.
Seconding the recommendation to defrag; building our app on my machine went from 40-70 minutes down to 15-20 after cleaning up and defragging. I was amazed how much difference it made, to be honest.
Dan Mitchell
Use an SSD drive instead of a traditional HD
Peter Gfader

A good list of Visual C++ tips is here:

Kristopher Johnson
+2  A: 

The single biggest thing you can do to improve the speed of VS 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.

Robert C. Barth
Ankh SVN is faster !
Nicolas Dorier
VisualHG is fast too!
Marcus Lindblom
+17  A: 

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 IO of the virus checker decreased the speed.

If you are able to do this, also try setting the process priority of the virus checker lower than normal.
Mike Atlas

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

Nothing to do with the IDE.
Nick Bedford

Disabling the Splash screen seems (psychological?) to make VS load faster.

To disable it, modify the shortcut to this: "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.

+3  A: 

If you are using Vista, change the theme to windows standard, in short stop using the Aero thing.

And i've observed on my system with Vista biz edition having 2gb ram on core 2 duo, that having VS, SQL Server Mgmt Studio and Outlook, all these 3 opened simultaneously has a major kick on performance.

If using TFS, then keeping the Source control explorer always open in VS08 too slows down VS. One can have a button to bring open SCE window on a toolbar.

Kunal S
+2  A: 

Snippet Designer On CodePlex


I wrote a smallish post on increasing the load time on larger project that some might find interesting get it here

+1  A: 

are you also referring to short cut keys to speed up development time?

If so, ALT + highlight with left mouse click allows u to select a "box" of text. Extremely useful.

nice tip, but i'm looking for things that will speed up the IDE
why would that be useful? Code is still code and selecting it as whole lines is better simpler, more error prone...
Robert Koritnik
may not be as useful in VS coding, but certainly in the sql management studio when writing ur stored proc.
+5  A: 

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 this link for reference and how-to:

This is especially true with running Visual Studio 2010 on a 32-bit system, in conjunction with TFS, MSTest and a couple of other things. VS2010 is designed to keep the maximum virtual memory usage at about 1.6 GB, but if you're doing a lot of stuff, free memory in the process can get pretty fragmented, and eventually you hit a point where you can't even do basic operations like copy/paste anymore.
Also, the /3GB switch is an XP thing... you need to use the BCDEDIT command-line tool on Vista and later.
+2  A: 

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

I would recommend either a free Gavotte Ramdisk or commercial product from QSoft.

I used Gavotte (which is quite fine) and now I'm running on QSoft (it can automatically save/load your ramdrive 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 happy customer :)

Piotr Owsiak
Use an SSD drive!
Peter Gfader
Aren't there ways to up Windows' cache, instead of needing to use a seperate RAM disk?
@Mark: I don't know, are there reliable ways to do that? I've heard that Windows won't take more than 1/8th of your RAM as disk cache (this does not apply to servers) even if there's plenty free. This is opposite to Linux that will take "all" your free RAM memory to cache disk operations. I wish there was such option in Windows.
Piotr Owsiak
@Peter Gfader: I'm sure you'll agree that SSD still is slower than RAM, right? However SSD will give you additional speed increase since assemblies/DLLs that you cannot move to ram drive will be loaded faster (i.e. your GAC, msbuils stuff, etc.).RAM drive will help you speed up operations on your solution like "Find in files", "Search and replace", build, etc.SSD will help you speed up VS launch time and your solution build time (which is also important i.e. when doing TDD).
Piotr Owsiak
Also if you're developing ASP.NET apps and run them on your local machine you will benefit from setting the TEMP directory to your ramdisk. ASP.NET compiler puts assemblies there (look for something like "Temporary ASP.NET Files" folder)
Piotr Owsiak
+3  A: 

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) VS will freeze up for 30+ seconds after a launched project terminates, instead of letting control return to the code editor immediately.

Andrew Medico

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

On so that you get something better when it comes, or off so that you don't waste time checking for it?
Daniel Daranas
I've often worked with VSS for a very long time and noticed X and Y were slow or not working well (costing me time) ... turns out there is a fix for it, it's in the updates.
+5  A: 

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
   ProcessFound = True
  End If

 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.

Bit Destroyer
Calling this Macro on a breakpoint when hit and continue execution is a great way to save even more time!
Mike Atlas
Use Firefox to debug and you can reuse the existent tab...
Peter Gfader
+4  A: 

Life Changing XAML Editing Tip

If you get annoyed at VS hanging for a few seconds when you try and edit XAML, this will improve things no end. It works so well I dont really understand why its not the default behaviour.

WOW!!! It works! Even on VS 2010
Andrei Rinea
  1. Incredibuild is really amazing stuff. In my case 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 2 HDD, put the source code and SWAP on different drives.
Iuliu Atudosiei

Use the magic C++ "Unity build" technique...

it's actually amazing: 20min to 3min minimum rebuild/link time for us.

+2  A: 

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

There is a tiny tool called KatMouse 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!

sweeeeeeeeeeeeeeeeeet :)

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 ^^

Oskar Duveborn
Is that a computer-wide setting or part of the individual app?
An individual setting inside the application... these are rather new to both apps mentioned.
Oskar Duveborn
+8  A: 

Empty your Recycle Bin.

+6  A: 

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)

Martin S.
FWIW, errors in HTML/CSS **are** “actual errors”. Why should they be turned off?
Konrad Rudolph
Because we're better off validating HTML and CSS elsewhere, rather than inside Visual Studio.You'd very often want to see actual build errors in the Error list rather than HTML and CSS errors - which, actually might not be errors - only Visual Studio misinterpreting web standards.Also, Visual Studio doesn't have support for XHTML Strict and I guess that means no validation for XHTML Strict, which probably is one of the most used doctypes on modern websites.
Martin S.
+8  A: 

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.

Ben Aston