VS.NET 2005 - questions, questions, questions

Hi everyone,

I don't want to be the party pooper (where did that phrase originate from anyway, I bet there is a good story behind that), but is anyone else experiencing extreme difficulties in house breaking VS.NET 2005?

I love the features of the .NET 2.0 framework, but VS.NET is behaving waywardly and not playing very nice with said features.

When I first start VS.NET it consumes upwards of 45% of my CPU and over 200 Mb of memory. (figure 1):

figure 1

It should also be noted that this solution is fairly small, consisting of 3 small C# project's.  Also, I am primarily a Middleware developer, and this is a WinForms solution, so maybe I am just not used to the overhead of VS loading all the visual controls.

Once the solution is entirely loaded in VS (Average time is about 3 or 4 minutes), the devenv.exe memory remains consistent at around 350 Mb, which seems rather high to me as that is over 33% of available memory for me.

Anytime I need to switch to a visual designer view and add or edit a control, I have to wait an additional 2 to 4 minutes for the designer to refresh.

All in All I feel as though I am wasting ALOT of time that I need to be able to account for (plus the added frustration of twiddling my thumbs while I wait for a tool to initialize)

Are other people experiencing similar issues and are there any tweaks that can be done to improve the performance of VS 2005?

If you have any tidbit of info that might help speed me up even a little, please reply.


[C]

Hmm, I experience occasional delays in VS2005, but nothing too bad. Definitely not so severe.

Starting it takes only a few seconds, there's no high CPU usage, and memory usage before loading a solution is only 23MB.

Sven Groot wrote:

Hmm, I experience occasional delays in VS2005, but nothing too bad. Definitely not so severe.

Starting it takes only a few seconds, there's no high CPU usage, and memory usage before loading a solution is only 23MB.

I wonder if it is just the overhead of the Visual Controls, forms and Components. This is my first project in years that has a UI, so my first reaction was that it must be related to that; but perhaps I just got a shady install.

I think I may have narrowed one of the offending culprits down to one (or two) of DevEx's VS Controls.

H4L0PR1CK wrote:

Sven Groot wrote: Hmm, I experience occasional delays in VS2005, but nothing too bad. Definitely not so severe. Starting it takes only a few seconds, there's no high CPU usage, and memory usage before loading a solution is only 23MB.

I wonder if it is just the overhead of the Visual Controls, forms and Components. This is my first project in years that has a UI, so my first reaction was that it must be related to that; but perhaps I just got a shady install.

I think I may have narrowed one of the offending culprits down to one (or two) of DevEx's VS Controls.

Are you working on VB.Net projects?

NuTcAsE wrote:

Are you working on VB.Net projects?

Nope, only C#.

Sometimes my machine becomes so bogged down with VS.NET processing that it results in a 1 second delay when typing charcters, even in Code View.

This is driving me completely bonkers.

Looks like you are running Norton AV.  I had some of the same problems because our admin's had norton setup to scan *.*.  You might try temporarily disabling your virus scan and see if it gets better.  If it does, then add your source code directories to the exclusions list for norton.

This won't help the memory usage, but it sped up VS tons.. especially build times.

btw - My memory usage is about the same as yours.  I'm generally working in smaller web or winform apps.  250-350MB for devenv.exe is about normal for me.

Thanks for the 411 SodaPop, I will follow your suggestion and add my project folders to Norton's exclusion list.

Stay Golden and Do it for Johnny.

i noticed this today also, but in C# Web Application Project (WAP's) - my devenv was at 150 MB and slow as heck. I turned off the HTML validation and it got a little better. I have had no issues with Class Library projects.

I'm currently running VS2005 on a Dual-800Mhz PC with 128MB.

I have a rather huge project loaded now, and devenv is consuming about 11MB.

I seem to recall there was an issue moving from the Beta/RCs to the RTM product, that resulted in this sort of caper... and required that you run a special "nuke all previous installs" app to completely clear out all the Beta/RC stuff... as the unistalls left a heap of crap behind.

This level of memory usage is also the norm for me when using VS2005 (which just stays open at work) ...... The machine is running 2GB(2x1GB) of DDR400 in single channel (mobo limitation).... the 200MB usage goes widely un-noticed.

while working on my current console app the environment is about 192MB or so..... the same goes for our large website projects(which include a large list of installed 3rd party controls)

I think i may need to look at seeing if there are any updates since its the install from the launch party..........

I also find it's not uncommon for this kind of memory usage. I actually bought an extra gig of RAM for my laptop to help deal with some of the increased needs of VS.NET 2005 and SQL Server 2005

still get memory hogging issues, but increased speed...found this post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=144370&SiteID=1

ScaleOvenStove wrote:

still get memory hogging issues, but increased speed...found this post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=144370&SiteID=1

Wow, that did speed me up significantly.

I love you.

I noticed and heard while at Redmond that small files are an objective for source code. Specialization one task::class::file.
Partial classes are another way to "partition" code into smaller source files.

This tip was for writing better code, not optimizing VS code editor. Maybe it can do both.

JohnAskew wrote:

I noticed and heard while at Redmond that small files are an objective for source code. Specialization one task::class::file.
Partial classes are another way to "partition" code into smaller source files.

This tip was for writing better code, not optimizing VS code editor. Maybe it can do both.

Thanks, John.

As a strong advocate of Agile Systems and TDD, I am already implementing this strategy through various patterns and practices.

The smell you described, "Single Responsibility"; can and should be encapsulated in a "Command" pattern, which I make extensive use of.

Excellent point though.

JohnAskew wrote:

I noticed and heard while at Redmond that small files are an objective for source code. Specialization one task::class::file.
Partial classes are another way to "partition" code into smaller source files.

This tip was for writing better code, not optimizing VS code editor. Maybe it can do both.

Not sure if we are talking the same thing, but I must admit that I make extensive use of the 'partial' modifier in all my VS2005 projects, to split up the code into small 'editable' source-code units.

Originally, I did it just because it made my life a lot easier... being able to select just the section I need to work on, rather than scroll through thousands of lines... but if so happens that it's also the reason VS2005 runs so well on my 'antique' equipment... then that's cool with me.

The VS 2005 editor is also unusable for us on a couple C# files. Partial classes don't help as these files must compile in .net 1.1 as well. We would like to split them up more, but it is difficult, as certain constraints in the design-time infrastructure make that harder.

There is something wrong with a product that progressively becomes slower and more buggy with each release.

Frank Hileman wrote:

The VS 2005 editor is also unusable for us on a couple C# files. Partial classes don't help as these files must compile in .net 1.1 as well. We would like to split them up more, but it is difficult, as certain constraints in the design-time infrastructure make that harder.

There is something wrong with a product that progressively becomes slower and more buggy with each release.

Frank,

Did you take ScaleOvenStove's advice of following the instructions @
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=144370&SiteID=1

Also, how big are these unusable C# class files?

Have you thought about the possibility of refactoring these huge classes into smaller pieces, perhaps be implementing different design patterns where appropriate?