Decrease the Memory Footprint
Since Visual Studio is a tool which can be used in so many scenarios (desktop development, web development, game development, etc) and supports so many languages (managed, native, scripting) it seems it is often loading tools and editors which are not needed for the current scenario.
It would be nice to have very fine grain control over what components are loaded at any given time to decrease the memory footprint and increase the performance.
For example, if I just want to edit a C# file in a class library it seems the memory footprint could be much smaller than when doing something like WPF development with a design surface, data access, etc.
lfoust
shared this idea
Improvements in virtual memory usage are now available for Beta testing with the VS11 Beta. Download VS11 Beta to try it out, and share your thoughts with us. For more details on the virtual memory improvements you’ll find in the Beta, see http://blogs.msdn.com/b/visualstudio/archive/2012/03/05/visual-studio-11-beta-performance-part-1.aspx
8 comments
-
![David Berg [msft]](http://www.gravatar.com/avatar/435e500d8269abb10ac8c417f1a1abae?size=40&default=http://cdn.uservoice.com/images/admin/icons/user_40.png)
David Berg [msft]
commented
Memory takes two forms. Virtual Address Space which for a 32 bit process, like VS, is limited to 2 or 4GB depending on whether your running 32 or 64 bit Windows. Working Set which is the memory actively used. When we run out of Virtual Address Space we crash. When we use too much Working Set we get slow. Buying more memory helps with working set, but not Virtual Address Space. Which memory are people most concerned about?
-
Victor Zakharov
commented
Good thoughts, but not a deal breaker. Simple solution - get 16GB of memory. It would be under 100$ for a pack. You are paying $17K+ for a Visual Studio Ultimate license and cannot afford 100$ for a memory upgrade? For reference, here is a price proof link: http://www.microsoftstore.com/store/msca/en_CA/pdp/productID.254742100
-
codekaizen
commented
I'd rather have a faster VS than a more parsimonious one; 8GB of RAM is cheap, and can easily run 3+ instances of VS with room to grow. While not being wasteful is commendable, speed often comes at the cost of space.
-
Anonymous
commented
How often have you accidently went to open a web.config on its own to pull out a connection string only to groan as you see the VS splash screen sitting there. There are a couple of things you could do here:
1: make visual studio smart enough to realise when you're opening a single (non .sln/.csproj) file to spin up a lightweight version of the editor. Something like this got installed as a side effect of putting vwd express on my web server. Its very quick, has intellisense and the 'correct' vs color coding
2: Throw up a prompt - 'Are you sure you want to use VS for this single file?'
3: Buy out editplus, replace notepad with it and make it the default text editor. Or at least see how they get so much functionality in a 900k exe :) -
drweb86
commented
Yea, could you please add performance troubleshoot to visual studio ? Which will analyze usage of visual studio and hardware and will give advices and will not load all unused and rarely used components and tools. Also could you please create something like dump of visual studio, so new instance can be loaded in memory like from hibernate?
-
David Nelson
commented
@Alexander, 64-bit VS would dramatically INCREASE the memory footprint. How would that help?
-
Alexander Buryak
commented
Small footprint is a good thing, but 64bits VS build could solve the problem even more effectively.
-
David Nelson
commented
It is not uncommon for me to have 5 Visual Studio instances open at the same time, all of them using between 1/2 and 1 gig of memory, even when the solutions have only a few projects with a few dozen files each. EVERYTHING in Visual Studio should be modular and only loaded when needed; not just delay-loaded, but actually UNloaded when its not being used.
