Visual Studio compiles slowly, low CPU usage

[Bruno Jouhier [MVP]]

I'm currently experiencing a strange phenomenon:

At my Office, Visual Studio takes a very long time to compile our solution
(more than 1 minute for the first project).
At home, Visual Studio compiles the same solution much faster (about 10
seconds for the first project).

My home computer is only marginally faster than the one I have at the office
(P4 2.53 vs. P4 2.4, same amount of RAM).
On the slow machine, the CPU usage is very low, especially at the end of the
compilation phase (once the progress bar is at the end, waiting for the
"build complete" message). This low CPU phase seems to account for the
difference in overall time. There is no other process taking CPU during that
time (the "overall" CPU usage is 0 or very close to 0).

Also, we observe the same slowness on all the machines that we have in our
office. And the behavior is not due to the corporate antivirus because we
turned it off.

I'm puzzled (and a bit frustrated). Could this be due to the fact that we
are on a corporate LAN and that .NET needs to run more expensive security
checks that block on network requests. This my only hypothesis so far
because I saw small bursts of activity in lsass.exe during the low CPU
phase.

Anybody experienced something like this? Any clues on what could cause this?

Bruno.

 

[NULL]

I'm currently experiencing a strange phenomenon:

At my Office, Visual Studio takes a very long time to compile our solution
(more than 1 minute for the first project).
At home, Visual Studio compiles the same solution much faster (about 10
seconds for the first project).

My home computer is only marginally faster than the one I have at the office
(P4 2.53 vs. P4 2.4, same amount of RAM).
On the slow machine, the CPU usage is very low, especially at the end of the
compilation phase (once the progress bar is at the end, waiting for the
"build complete" message). This low CPU phase seems to account for the
difference in overall time. There is no other process taking CPU during that
time (the "overall" CPU usage is 0 or very close to 0).

Also, we observe the same slowness on all the machines that we have in our
office. And the behavior is not due to the corporate antivirus because we
turned it off.

I'm puzzled (and a bit frustrated). Could this be due to the fact that we
are on a corporate LAN and that .NET needs to run more expensive security
checks that block on network requests. This my only hypothesis so far
because I saw small bursts of activity in lsass.exe during the low CPU
phase.

Could be... I know it is possible to run VS.net for a group of
developpers on a server... Most likely at your workplace, the VS.net
will be running from a server (hence the 'overall CPU usage' being so
low) end thus needs to be shared with your co-workers...

Bully them untill they give up using it whenever you need it

How did you perform the installation of VS.net? Was it installed
localy (if so, my answer here is not to be considered)?

 

[Michael Culley]

I've experienced this problem when the source files have been stored on a network drive. In my case it turned out to be a slow
router and changing it with a hub solved the problem. What transfer rate are you getting from your server?

The best solution would probably be to use sourcesafe, that way all files are on your local machine and network speed is not
important.

 

[Bruno Jouhier [MVP]]

Visual Studio is installed locally and the source files are local too (we
use CVS as source code control).
So the explanation is somewhere else.

Thanks anyway for the quick reply.

Bruno

 

[Bruno Jouhier [MVP]]

Visual Studio is installed locally and the source files are local too (we
use CVS as source code control).
So the explanation is somewhere else.

Thanks anyway for the quick reply.

Bruno

I've experienced this problem when the source files have been stored on a

network drive. In my case it turned out to be a slow

router and changing it with a hub solved the problem. What transfer rate

are you getting from your server?

The best solution would probably be to use sourcesafe, that way all files

are on your local machine and network speed is not

 

[Bruno Jouhier [MVP]]

Visual Studio is installed locally and the source files are local too (we
use CVS as source code control).
So the explanation is somewhere else.

Thanks anyway for the quick reply.

Bruno

 

[Bruno Jouhier [MVP]]

Visual Studio is installed locally and the source files are local too (we
use CVS as source code control).
So the explanation is somewhere else.

Thanks anyway for the quick reply.

Bruno

I've experienced this problem when the source files have been stored on a

network drive. In my case it turned out to be a slow

router and changing it with a hub solved the problem. What transfer rate

are you getting from your server?

The best solution would probably be to use sourcesafe, that way all files

are on your local machine and network speed is not

 

[Bruno Jouhier [MVP]]

Visual Studio is installed locally and the source files are local too (we
use CVS as source code control).
So the explanation is somewhere else.

Thanks anyway for the quick reply.

Bruno

 

[Bert Roos]

H Bruno,

Could it be because you have network shares/drives in your PATH? I've had
similar problems caused by a network share on a computer that was offline.

Regards, Bert

 

[Lee Alexander]

Bruno,

Make sure your disk is being slowed down by something like a defrag, that
will slow things down.

Regards
Lee

 

[Rob 'The Other Nice Man' Kenny]

I'm currently experiencing a strange phenomenon:

At my Office, Visual Studio takes a very long time to compile our solution
(more than 1 minute for the first project).
At home, Visual Studio compiles the same solution much faster (about 10
seconds for the first project).

My home computer is only marginally faster than the one I have at the office
(P4 2.53 vs. P4 2.4, same amount of RAM).
On the slow machine, the CPU usage is very low, especially at the end of the
compilation phase (once the progress bar is at the end, waiting for the
"build complete" message). This low CPU phase seems to account for the
difference in overall time. There is no other process taking CPU during that
time (the "overall" CPU usage is 0 or very close to 0).

Also, we observe the same slowness on all the machines that we have in our
office. And the behavior is not due to the corporate antivirus because we
turned it off.

I'm puzzled (and a bit frustrated). Could this be due to the fact that we
are on a corporate LAN and that .NET needs to run more expensive security
checks that block on network requests. This my only hypothesis so far
because I saw small bursts of activity in lsass.exe during the low CPU
phase.

Anybody experienced something like this? Any clues on what could cause this?

Bruno.

OK so the usual suspects are absent (Anti-Virus and Network
Read/Writes) lets look a bit deeper.

1) What OS and Service Packs are you running?
2) What other processes are running in the background?
3) Have you run Performance Monitor to check CPU / Disk / LSASS.EXE
etc.

 

[Thomas Ganss]

Check the installation:
many "company setups" install the OS on C:,
which is typically rather small, and this will get you a
fragmented swapdisk, and the system is always searching for
room to write the temporary files...

Searchpath can also be critical (especially on nonexsitant
drives <g>)

HTH

thomas

 

[james]

Could you possibly have the BLASTER visus worm ?

 

[Rob 'The Other Nice Man' Kenny]

What does LSASS.EXE actualli do, what is it?

Process File: lsass or lsass.exe
Process Name: Local Security Authority Service
Description: The Windows Local Security Authority Server Process
Handles Windows Security Mechanisms

The Lsass.exe process is responsible for management of local security
authority domain authentication and Active Directory management. This
process handles authentication for both the client and the server, and
it also governs the Active Directory engine. The Lsass.exe process is
responsible for the following components:

* Local Security Authority
* Net Logon service
* Security Accounts Manager service
* LSA Server service
* Secure Sockets Layer (SSL)
* Kerberos v5 authentication protocol
* NTLM authentication protocol

 

[Bruno Jouhier [MVP]]

C drive cannot be the culprit because there is only one drive (C and there
is plenty of room on it.
I'm going to check the searchpath. Thanks for the pointer.

Bruno.

 

[Bruno Jouhier [MVP]]

I have network shares but I don't think that they are in my PATH (but I'm
not sure). I'll check that tomorrow (at my office). Thanks for the pointer.

Bruno.

 

[Bruno Jouhier [MVP]]

1) What OS and Service Packs are you running?
XP pro sp1 with all the critical patches I could get from Windows Update
(same on both machines).

2) What other processes are running in the background?

SQL server is running (but idle).

3) Have you run Performance Monitor to check CPU / Disk / LSASS.EXE
etc.

Yes and I did not see any significant activity but I need to do more
research with perfmon. I did not monitor network or disk activity. Before
going too deep into monitoring, I wanted to check if anybody had experienced
something like this, and get the most obvious pointers.

So, I'll investigate the network shares in %PATH% (see other replies) and
I'll do a bit of perfmon testing if I don't find anything.

Bruno.

 

[Bruno Jouhier [MVP]]

No, I had run Windows Update a few days before the attack and my machine was
protected. Also, I ran the AntiVirus after the attack and it did not find
anything. So Blaster's not the culprit.

Bruno.

 

[Scot Rose [MSFT]]

Hi Bruno, Are you on a Domain at work? If so see

318738 FIX: .NET Programs Are Slow to Load When Running Under a Domain
http://support.microsoft.com/?id=318738

This is 'supposed' to be fixed, but might be worth a look. You may need to to have an ASPNet account set up according to the article..

Want to know more? Check out the MSDN Library at http://msdn.microsoft.com or the Microsoft Knowledge Base at http://support.microsoft.com

Scot Rose, MCSD
Microsoft Visual Basic Developer Support
Email : (e-mail address removed) <Remove word online. from address>

This posting is provided “AS IS”, with no warranties, and confers no rights.




--------------------

 

[Bruno Jouhier [MVP]]

Hi Scot,

Yes, we are running under a domain at work, and not at home. I looked at the
link but I don't think it explains our problem:

* The problem is not with the .NET apps that we create but with Visual
Studio .NET itself.

* Visual Studio starts normally (so the problem is not at load time). The
problem shows up at the end of compilation: CPU usage is very low (2% or
less) and stays like this for more than 1 minute before completing and
moving to the next project of our solution.

* We are running Studio 2003, so the underlying framework is 1.1 rather than
1.0.

One note: our solution mixes J# and C# projects. The first project that
takes the longuest to compile is a J# project which is referenced by all our
other projects. Depending on what we are building, we have between 5 and 46
projects in the solution but the problem does not seem to be related to the
number of projects in the solution.

Also, recently we have rewritten our resource handling to use the .NET
mechanisms (resx files) rather than our old Java scheme, and it seems that
the slow compile pb has worsened at about the same time. So, it may be
related to the build of satellite assemblies.

What I can't understand is why the compiler sits almost idle for long
seconds before completing compilation. It really looks like it's waiting for
some kind of network response (from the domain controller???).

Bruno.

Hi Bruno, Are you on a Domain at work? If so see

318738 FIX: .NET Programs Are Slow to Load When Running Under a Domain
http://support.microsoft.com/?id=318738

This is 'supposed' to be fixed, but might be worth a look. You may need to

to have an ASPNet account set up according to the article..

Want to know more? Check out the MSDN Library at http://msdn.microsoft.com

or the Microsoft Knowledge Base at http://support.microsoft.com