473,324 Members | 2,166 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

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

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

Apr 17 '07 #1
16 2183
Jon Davis <jo*@REMOVE.ME.PLEASE.jondavis.netwrote:

<snip>
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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 17 '07 #2
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
Apr 17 '07 #3
On Apr 17, 4:18 pm, "Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.net>
wrote:
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.

Apr 17 '07 #4

"Patrick" <pm*******@gmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...
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
Apr 17 '07 #5
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
"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:OE**************@TK2MSFTNGP02.phx.gbl...
>
"Patrick" <pm*******@gmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...
>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


Apr 18 '07 #6
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" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:ej**************@TK2MSFTNGP04.phx.gbl...
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
"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:OE**************@TK2MSFTNGP02.phx.gbl...
>>
"Patrick" <pm*******@gmail.comwrote in message
news:11**********************@o5g2000hsb.googlegr oups.com...
>>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).

Apr 18 '07 #7

"Paul Shapiro" <pa**@hideme.broadwayData.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
>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


Apr 18 '07 #8
On Wed, 18 Apr 2007 13:31:01 -0700, "Jon Davis"
<jo*@REMOVE.ME.PLEASE.jondavis.netwrote:
>
"Paul Shapiro" <pa**@hideme.broadwayData.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
>>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

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.

--
Philip Daniels
Apr 19 '07 #9
On Apr 18, 9:31 pm, "Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.net>
wrote:
"Paul Shapiro" <p...@hideme.broadwayData.comwrote in message
[...]
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/sys...n/bootini.mspx

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

Matt

Apr 19 '07 #10


<kt*******@sneakemail.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.com...
On Apr 18, 9:31 pm, "Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.net>
wrote:
>"Paul Shapiro" <p...@hideme.broadwayData.comwrote in message

[...]
>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/sys...n/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 ?
Apr 19 '07 #11
Ian Semmel <an****@rocketcomp.com.auwrote:
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 Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 19 '07 #12

<Ph***********@foo.comwrote in message
news:2f********************************@4ax.com...
On Wed, 18 Apr 2007 13:31:01 -0700, "Jon Davis"
<jo*@REMOVE.ME.PLEASE.jondavis.netwrote:
>>
"Paul Shapiro" <pa**@hideme.broadwayData.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl.. .
>>>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

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.
The old workstations are using Server 2003 without issue. The OS is already
ruled out.

Jon
Apr 20 '07 #13

<kt*******@sneakemail.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.com...
On Apr 18, 9:31 pm, "Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.net>
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/sys...n/bootini.mspx

The switch you need is /ONECPU (or /NUMPROC=1)
Good idea, but we tried that. Didn't help.

Jon
Apr 20 '07 #14

"Ian Semmel" <an****@rocketcomp.com.auwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
>

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
Apr 20 '07 #15

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
>
Are they running the same virus scanning software?
The new workstation does not have any virus scanning software installed.

Jon

Apr 22 '07 #16

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:Ox**************@TK2MSFTNGP02.phx.gbl...
>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

Apr 22 '07 #17

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Chris Kilmer | last post by:
I would like to be able to customize the path structure that VS.NET 2003 creates for projects. 1. I'd like to be able to create a project without VS.NET creating a folder for that project. ...
5
by: David Webb | last post by:
The problem started when the Working Folder for a project was somehow set to the folder of another project. I set the correct working folder in VSS and deleted the .vbproj files that had been...
1
by: Vladimír Kolesnik | last post by:
Hi, there we need help concerning setting project under source control. We want to have a project on the server, and developers in the local network working on this project. We decided to use...
2
by: Nathan Sokalski | last post by:
Because I wanted the builds for my ASP.NET sites to be a single *.dll in a /bin/ directory (like VSNET 2003), I decided to try the Web Application Project download. However, I am still pulling my...
6
by: Andrew Rowley | last post by:
I am having trouble getting debug and release builds to work properly with project references using C++ .NET and Visual Studio 2003. I created a test solution, with a basic Windows form C++...
7
by: uupi_duu | last post by:
Hello, Has VS.Net 2005 SP1 changed C# WebApp's project files? Can't open it anymore without installing SP1. Anyone know what is behind this? Cheers,
12
by: BDowling | last post by:
Hi all, I have an existing Visual C++ project that builds a DLL (not COM or ATL or anything). I wish to use this DLL in a Visual Studio 2005 C# project without having to define each function and...
10
by: =?Utf-8?B?TUNN?= | last post by:
When creating a new VB Web Application Project with VS2008, there are several settings (compiler settings, option strict, etc) that appear both in the web.config file and "My Project". I'm...
9
by: AWW | last post by:
Running XP - Visual Studio 2005 - VB Want to have duplicate projects - one safe and stable - other for experimenting Can't fine easy way to make duplicate project. Stupid question? or stupid ME?...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.