views:

263

answers:

3

Hi,

VS 2005 is taking a very very very long time to compile my C++ solution all of a sudden. I tried deleting the Intellisense DLL and deleting the .suo and .ncb files and that didn't help. Most of the time during my build Process Explorer shows almost all of the CPU time being spent in System Idle Process, so I have no idea what Visual Studio is wasting its time on.

Also, the "Team Manager" in Team System takes 8 years to update when you do anything. I tried the MS tip to disable "CMI" but it hasn't helped much.

Any ideas on how to speed things up?

edit: Not accessing stuff over network share. I had VSS integration on but I turned it off.

edit the second: Thanks for the help. Nothing really sticks out, I guess it's just a bad accumulation of stuff in VS. I'm just going to delete and reinstall VS 2005 and not install the Team Explorer stuff at all, hopefully that will help.

A: 

Solid state disk storage, more memory, and a faster machine. If you're using VS 2005 you're probably not cutting edge on the hardware side either...

David in Dakota
It used to work fine. My machine is a Pentium Dual E2180 @ 2 GHz with 2GB RAM. I'm using VS 2005 because it's an older solution.
evilfred
SSD storage? As a solution? Really? And you have to be on the "cutting edge of hardware" for a fast compile? You, also, probably missed the "all of a sudden" part.
foljs
A: 

Try deleting the temporary files in the project directory, especially the ncb, after closing down Visual Studio. That often fixes inexplicable slow down.

justinhj
+1  A: 

When things start to get substantially slower without any indication of activity (CPU, hard disk), then it's usually because some component is waiting for something else (often a network). Windows itself can go from responsive to unusably slow if its domain controller disappears or otherwise becomes unresponsive. A reboot often fixes this. Some things might depend on connectivity to the Internet to perform various tasks, which can cause slowdowns if the component making the request doesn't realise the network is unavailable.

I once ran into a situation where everything was taking much longer than seemed necessary. It turned out that the Windows "Security" event log was set to have a maximum size, was set to overwrite entries only after they were certain number of days old, and the event log was full. It appeared that whenever Windows wanted to write a security event log entry, the kernel would sit around and wait until the oldest entry was old enough to be deleted! I ended up having to power off the machine, log on as administrator, fix the settings, and reboot again.

Greg Hewgill