C# project builds SLOWER in Visual Studio on faster, new workstations

[Jon Davis]

We ordered new systems with fast hardware and great specs, but Visual Studio
takes longer to build a project than on the old workstation. Msbuild is
faster, csc.exe is faster, file copy is faster. But opening copying the
project files straight over from one workstation to the new workstation,
opening the projects locally on the new workstation, and running Build from
within the IDE, it's slower--much slower, like 30 seconds rather than 10
seconds. The Output window does not indicate differences. We diff'd the
Output log from the two workstations and only see shorter msbuild times on
the new workstation.

When building on the new workstation, Visual Studio temporarily freezes up,
about three or four times (-ish) during the process (I haven't counted). The
sum amount of time that Visual Studio freezes is roughly equivalent to the
extraneous amount of time it takes for everything to complete. The Output
window does *NOT* show what it's working on when it starts freezing because
it's in a completely different spot each time. But based on very minor
differences in the Output log it *seems* to be slightly different somewhere
around where it's calculating which dependencies to import, or resolving
paths. But I'm not ready to think that's probably related.

Both the old and new workstations have WD Raptor drives, 2GB RAM (new
workstation @800MHz), both running on AMD (old workstations running
single-core Athlons, new workstation running dual-core Athlon 6000+),
Windows Server 2003 (new workstation with SP2, neither workstations running
R2, and Programs [vs Background Services] are configured to have priority),
and Visual Studio 2005 with Service Pack 1.

Any ideas?

- Jon

 

[Jon Davis]

I should add, we have had several reboots, we've tried swapping out RAM, and
in fact we had the same problem on other new workstations based on Intel
(all multiple core).

I can't help but think that it's related to either

a) default configuration in Windows that something somehow is different in
our old workstation environments, despite having installed SP2 on the new
workstation and SP1 for Visual Studio and even importing the Visual Studio
settings from the old workstation onto the new workstation using the
Tools->Options team settings file import tool,

or b) multiple cores. But I haven't heard of anyone having this problem with
multiple cores??

I'm hoping someone else has seen this.

Jon

 

[Jon Skeet [C# MVP]]

Both the old and new workstations have WD Raptor drives, 2GB RAM (new
workstation @800MHz), both running on AMD (old workstations running
single-core Athlons, new workstation running dual-core Athlon 6000+),
Windows Server 2003 (new workstation with SP2, neither workstations running
R2, and Programs [vs Background Services] are configured to have priority),
and Visual Studio 2005 with Service Pack 1.

Any ideas?

Are they running the same virus scanning software?

 

[Patrick]

I should add, we have had several reboots, we've tried swapping out RAM, and
in fact we had the same problem on other new workstations based on Intel
(all multiple core).

I can't help but think that it's related to either

a) default configuration in Windows that something somehow is different in
our old workstation environments, despite having installed SP2 on the new
workstation and SP1 for Visual Studio and even importing the Visual Studio
settings from the old workstation onto the new workstation using the
Tools->Options team settings file import tool,

or b) multiple cores. But I haven't heard of anyone having this problem with
multiple cores??

I'm hoping someone else has seen this.

Jon

Well if you have a dual core and the processor speed is lower than on
your older machines you will notice a slow down. Since compiling can
only happen on one core it will be slower. Otherwise I don't really
see why it would be slower.

 

[Jon Davis]

Well if you have a dual core and the processor speed is lower than on
your older machines you will notice a slow down. Since compiling can
only happen on one core it will be slower. Otherwise I don't really
see why it would be slower.

Thanks, but it's not the compiler--as I mentioned in the first paragraph of
the OP, msbuild is faster, csc.exe is faster, and file copy is faster--it
seems to be the IDE. The new cpu is also 3GHz per core (old CPU was
2.21GHz).

Jon

 

[Jon Davis]

Anyone have any more ideas? The 10 seconds pushed to 30 seconds was just for
one project in the solution that has two or three dependencies; the solution
itself takes a two or three minutes and should only take about thirty
seconds at most. This is a killer on productivity especially when debugging
base/core libraries (which we do all the time). Are we stuck with our old
workstations??

Jon

 

[Paul Shapiro]

I think you mentioned the new workstations are running Windows 2003 Server
with SP2? There were a few significant performance issues in some cases with
SP2, but I don't remember the details. You could search for the details, or
try a workstation without SP2. Or add SP2 to one of your older/faster
workstations if it's not already on.
Paul Shapiro

 

[Jon Davis]

I think you mentioned the new workstations are running Windows 2003 Server
with SP2? There were a few significant performance issues in some cases
with SP2, but I don't remember the details. You could search for the
details, or try a workstation without SP2. Or add SP2 to one of your
older/faster workstations if it's not already on.
Paul Shapiro

Considered that, but *both* the old and new workstations (there is only one
new workstation) have Win2k3 SP2 and the old workstation is *without* the
few-seconds IDE freeze issue. So unless there's specifically a conflict of
SP2 with something else on the default setup on the new workstation that the
old workstation doesn't have (and the old workstation has everything on it
that the new workstation has plus a lot more), that cannot be related.


Regarding this issue on the whole, we are seriously considering the notion
that Visual Studio is suffering from some kind of racing condition, where
it's starting to wait for something to happen (i.e. file copy event,
perhaps), but it already happened, so it waits for a few seconds until it
gives up.

We are also considering the notion that Visual Studio is not "compatible"
(in this regard) to support dual-core Athlons, since a nearly identical
symptom was experienced, so I am told by my boss, on some of our dual-core
Intels that was resolved from Visual Studio 2005 Service Pack 1. In other
words, Service Pack 1 fixed the performance issue with dual-core Intels but
not the dual-core AMDs.

Jon

 

[PhilipDaniels]

Jon

Hi Jon, why not try wiping one of the workstations and install another
OS such as XP or Vista? I doubt that many people are running Visual
Studio on a server OS, it may at least help narrow it down to an
OS/software issue rather than a hardware one.

 

[ktrvnbq02]

[...]

We are also considering the notion that Visual Studio is not "compatible"
(in this regard) to support dual-core Athlons, since a nearly identical
symptom was experienced, so I am told by my boss, on some of our dual-core
Intels that was resolved from Visual Studio 2005 Service Pack 1. In other
words, Service Pack 1 fixed the performance issue with dual-core Intels but
not the dual-core AMDs.

If you have suspicions about dual-core compatibility, you could try
telling Windows to use only one CPU core and see if you can observe
any difference. You can do this via boot.ini, see here:

http://www.microsoft.com/technet/sysinternals/information/bootini.mspx

The switch you need is /ONECPU (or /NUMPROC=1)


Regards,

Matt

 

[Ian Semmel]

[...]

We are also considering the notion that Visual Studio is not "compatible"
(in this regard) to support dual-core Athlons, since a nearly identical
symptom was experienced, so I am told by my boss, on some of our
dual-core
Intels that was resolved from Visual Studio 2005 Service Pack 1. In other
words, Service Pack 1 fixed the performance issue with dual-core Intels
but
not the dual-core AMDs.

If you have suspicions about dual-core compatibility, you could try
telling Windows to use only one CPU core and see if you can observe
any difference. You can do this via boot.ini, see here:

http://www.microsoft.com/technet/sysinternals/information/bootini.mspx

The switch you need is /ONECPU (or /NUMPROC=1)

Why would/should programs know how many cpus the system has and how do they
utilize this info ?

 

[Jon Skeet [C# MVP]]

Why would/should programs know how many cpus the system has and how do they
utilize this info ?

If you're running a highly parallel, CPU-intensive algorithm, it makes
sense to use as many threads as there are CPUs. You don't get the cost
of excessive context switches and synchronization associated with using
more threads than CPUs, but you also don't waste any CPUs.

 

[Jon Davis]

Hi Jon, why not try wiping one of the workstations and install another
OS such as XP or Vista? I doubt that many people are running Visual
Studio on a server OS, it may at least help narrow it down to an
OS/software issue rather than a hardware one.

The old workstations are using Server 2003 without issue. The OS is already
ruled out.

Jon

 

[Jon Davis]

On Apr 18, 9:31 pm, "Jon Davis" <[email protected]>
wrote:

If you have suspicions about dual-core compatibility, you could try
telling Windows to use only one CPU core and see if you can observe
any difference. You can do this via boot.ini, see here:

http://www.microsoft.com/technet/sysinternals/information/bootini.mspx

The switch you need is /ONECPU (or /NUMPROC=1)

Good idea, but we tried that. Didn't help.

Jon

 

[Jon Davis]

Why would/should programs know how many cpus the system has and how do
they utilize this info ?

Application threads are bound to and/or are parallelized across CPUs. They
don't have to know how many processes are running, but they do already know
how they are threaded. And if an application stalls while performing an
action, it is typically a threading issue. Since threads and CPUs are akin
to cars and passengers, ... well, you get the idea.

Jon

 

[Jon Davis]

Are they running the same virus scanning software?

The new workstation does not have any virus scanning software installed.

Jon

 

[Jon Davis]

I should add, we have had several reboots, we've tried swapping out RAM,
and in fact we had the same problem on other new workstations based on
Intel (all multiple core).

I can't help but think that it's related to either

a) default configuration in Windows that something somehow is different in
our old workstation environments, despite having installed SP2 on the new
workstation and SP1 for Visual Studio and even importing the Visual Studio
settings from the old workstation onto the new workstation using the
Tools->Options team settings file import tool,

or b) multiple cores. But I haven't heard of anyone having this problem
with multiple cores??

I'm hoping someone else has seen this.

Jon

The boss gave up and doesn't want to talk about this anymore. Initially I
said that we could live with it, but testing the compilation of the entire
solution and watching Visual Studio literally hang indefinitely on it, after
a lot of thought I feel fairly strongly that the obvious choices we are
stuck with are either use single-core Athlon or dual-core Intel CPU.

But we ended up getting dual-core Athlon XP2 6000+ workstations, since
outside of this specific problem and despite its thermal heat, it and the
motherboard chipset I/O together pack the most bang for the buck.

As for this issue, as I said, msbuild isn't affected, and I'm sure hoping
Microsoft is paying attention to the problem since it's obviously a bug in
Visual Studio, but meanwhile we are going to try using MSBuild as an
External Tool and manually attach the process to debug. (This sucks.) Some
Visual Studio extensibility might be called for here; getting the
compile-time error logs and continuation inturruption is important, as is
the importance of F5 debugging where if we have to manually attach our
process we'll be wasting a lot of time where the workstation upgrade
ultimately doesn't pay for itself.

Jon