views:

531

answers:

4

I have a solution with just under 100 projects in it, a mix of C++ and C# (mostly C#). When working in VS2005, the working set of Visual Studio is considerably smaller than that of VS2010.

I was wondering if there are some things that can be turned off, so I can develop in VS2010 under 32-bit OS without running out of memory.

+3  A: 

The best thing you can do is to split up your solution. Visual Studio wasn't meant to handle so many projects in the same solution and does suffer performance problems as a result. Splitting up your solution into 5 different ones will make things better.

JaredPar
Not true re: the OS. A 64-bit OS can in fact give 32-bit processes much more VM than a 32-bit process can. http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
Dave Markle
@Dave it's true that an application designed to take advantage can. I do not believe Visual Studio does this.
JaredPar
@Jared: Just to check, I ran dumpbin /headers on devenv.exe, and confirmed that Visual Studio *can* access > 2GB, since the "Application can handle large (>2GB) addresses" flag is set.
Dave Markle
@Dave, learn something new every day :). I'll edit my answer.
JaredPar
@Jared: That's why I love SO!
Dave Markle
Just FYI, SQL management stusio and SQL instance services can take advantage too.
GregC
+2  A: 

If you're on XP, upgrading to Vista or Windows 7 will help as it uses WPF. May reduce the memory footprint of the UI rendering which would otherwise have to use compatibility mode.

Chris Dennett
Upgrading to Windows 7 will help. Vista -- not so much. They made radical improvements to the memory utilization of the graphics stack in Windows 7. Actually, let's just pretend Vista never happened.
Dave Markle
+5  A: 

A 64-bit OS should help you out a bit here, if you get more than 4GB of physical RAM. A 64-bit OS can provide 32-bit processes with a full 4 GB of virtual memory, whereas a 32-bit OS only can provide 2 or 3 gigs at best, depending on how you boot the OS.

That being said, 100 projects is a pretty fat solution file. Maybe now would be a good time to reexamine that decision...

EDIT: Running dumpbin /headers as prescribed in the article for DEVENV.EXE returns:

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               4 number of sections
        4BA1FAB3 time date stamp Thu Mar 18 06:04:35 2010
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             122 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   32 bit word machine

So that would indicate that an x64 box with > 4GB of RAM will probably improve your experience. You should have up to twice as much VM available for Visual Studio under a 64-bit OS...

Dave Markle
This sounds like a good solution, and we're definitely headed down that path. One thing to note: I turned off automatic reindexing of C++ source code, and that seemed to help with CPU utilization as well as memory footprint.
GregC
Under tools->options->Text Editors->C++ -> Advanced
GregC
+2  A: 

You can try using the Solution Load Manager. It'll let you mark some of the projects files as load on demand or not load at all. That may help.

Noah Richards