Visual Studio can be a tremendous resource hog, especially if you
have a large solution and you're using a productivity add-in or two.
On my current project we're running VS 2008, we've got just under 20 projects in the solution, and several of us are using the ReSharper 4.0 EAP nightly builds
to enhance our dev-fu. And you know what... we're restarting VS at
least a half dozen times a day to work around a nasty exception we
regularly encounter while trying to compile:
Not enough storage is available to complete this operation.
Not enough storage...?
Yep - storage. But you should read storage to mean memory... RAM that is.
After
running for a while the Visual Studio process (found under devenv.exe
in process explorer) maxes out its available memory and the above
exception is thrown. The only way to reclaim the memory and successfully
compile the solution is to restart the process. Bummer!
Maybe we should just upgrade our hardware, right?
I
mean, with cost of processor cycles and RAM falling as fast as gas
prices are rising, why not just spend a few bucks and make sure we're
all running multi-core boxes with 4+ Gigabytes of memory and storage
space to burn. Well guess what... we are.
All of the developers
are running nice beefy machines with lots of RAM, super-fast processors,
and we even have nice 21" wide screen DVI monitors. So this ain't no hardware problem.
Its a software problem.
I
will admit, we are running a mix of 32-bit operating systems - mostly
Vista with a handful of XP machines mixed in for the devs that roll that
way. And Jeff Atwood has covered the missing RAM problem before, but even switching to a 64-bit OS wouldn't solve our problem. At least not entirely.
The
problem is with Visual Studio. Being a 32-bit application its limited
to just 2GB of virtual memory, even if its running in a 64-bit OS. At
least, its limited to 2GB by default... but we can hack around change that.
The hack... err, solution.
The first thing to do is tell the OS to increase the amount user-mode memory from 2GB to 3GB. If you're running a 64-bit you can skip this step.
- for Windows XP: Backup the
boot.inifile and then put the /3GB switch in yourboot.ini. (more information on the /3GB option) - for Vista: run the following from the Visual Studio command prompt (Brad Rutkowski has the full scoop):
1: BCDEDIT /Set IncreaseUserVa 3072
Note:
the boot.ini is a hidden file at the root of c:. You have to go into
explorer/tools/options and set view to include system and hidden files.
Now you will be able to see it.
You can also go to Run and type "edit c:\boot.ini".
Then we have make Visual Studio large address aware.
- Be sure to backup
devenv.exe - Using the Visual Studio command prompt, navigate to
C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\ - execute the following command:
1: editbin /LARGEADDRESSAWARE devenv.exe
Finally we'll use the old Microsoft-fix-all - reboot the machine. Bounce that box!
Look at all that memory!
At this point Visual Studio should be allowed to consume up to 3GB of memory before throwing that ugly out of memory exception.
Just to show you I'm not lying, I grabbed a screen shot of my process explorer with devenv.exe process chewing up more than 2.5GB of memory. Sweet!
Note: even with our large solution and running the early,
and memory-hungry, ReSharper bits, Visual Studio typically stays around
or just above the 2GB mark. However it can spike up to 2.5+ GB while
compiling, as show in this screen shot.
Notes: We also need to avoid binding errors in runtime.