I am so frusterated with how slow MSVC is

  • Thread starter Thread starter Chris Stankevitz
  • Start date Start date
C

Chris Stankevitz

I can't tell you how frusterated I and my coworkers are with "MSVC 7.1 .net
2003" (what am I supposed to call this thing anyway?).

Compiling and linking take twice as long with "MSVC 7.1 .net 2003" than with
MSVC 6. My coworkers are angry at "MSVC .net 7.1 2003" and they're angry at
me for pushing it (due to better C++ compliance).

The problem is so pronounced, I'm shocked that this message board isn't full
of people complaining. My guess is that our project is somehow different
and "MSVC 7.1 .net 2003" has an extra hard time with it. We have 68
projects with approx. 15 files in each project. We use wxWidgets.

Also very frusterating is the way the IDE stops responding when doing things
like a) preparing to compile b) compiling c) linking. Even starting the
IDE is a painfull experience, but luckily I only do that a couple times per
day.

Not to mention that when I change one .cpp in one of my projects, "MSVC 7.1
..net 2003" slowly loops through all the projects to see if anything needs to
be recompiled and does a very time consuming full link. Makes it very
difficult to make quick changes and debug (unlike MSVC 6).

If MSVC didn't have such a wonderful breakpoint/watch-window interface, we'd
have moved to distcc builds on cygwin. Faster and the makefile approach
allows for different configurations without putting togeter a billion .sln
and .vcproj files (maintenance nightmare).

I'm sorry to sound like a crank, but I am just so worked up and have to come
vent every month or so.

Rudy
 
Chris said:
I can't tell you how frusterated I and my coworkers are with "MSVC
7.1 .net 2003" (what am I supposed to call this thing anyway?).

Compiling and linking take twice as long with "MSVC 7.1 .net 2003"
than with MSVC 6. My coworkers are angry at "MSVC .net 7.1 2003" and
they're angry at me for pushing it (due to better C++ compliance).

The problem is so pronounced, I'm shocked that this message board
isn't full of people complaining. My guess is that our project is
somehow different and "MSVC 7.1 .net 2003" has an extra hard time
with it. We have 68 projects with approx. 15 files in each project. We
use wxWidgets.
Click to expand...

It's the large number of projects in the solution that has the largest
impact. The good news is that VS 2005 is back near the speed of VC6 for
building.

-cd
 
Chris said:
I can't tell you how frusterated I and my coworkers are with "MSVC 7.1 .net
2003" (what am I supposed to call this thing anyway?).

Compiling and linking take twice as long with "MSVC 7.1 .net 2003" than with
MSVC 6. My coworkers are angry at "MSVC .net 7.1 2003" and they're angry at
me for pushing it (due to better C++ compliance).

The problem is so pronounced, I'm shocked that this message board isn't full
of people complaining. My guess is that our project is somehow different
and "MSVC 7.1 .net 2003" has an extra hard time with it. We have 68
projects with approx. 15 files in each project. We use wxWidgets.

Also very frusterating is the way the IDE stops responding when doing things
like a) preparing to compile b) compiling c) linking. Even starting the
IDE is a painfull experience, but luckily I only do that a couple times per
day.

Not to mention that when I change one .cpp in one of my projects, "MSVC 7.1
.net 2003" slowly loops through all the projects to see if anything needs to
be recompiled and does a very time consuming full link. Makes it very
difficult to make quick changes and debug (unlike MSVC 6).

If MSVC didn't have such a wonderful breakpoint/watch-window interface, we'd
have moved to distcc builds on cygwin. Faster and the makefile approach
allows for different configurations without putting togeter a billion .sln
and .vcproj files (maintenance nightmare).

I'm sorry to sound like a crank, but I am just so worked up and have to come
vent every month or so.

Rudy
Click to expand...


The dependency checking for a build can be more or less fixed with a
visual studio plugin

http://www.workspacewhiz.com/FastSolutionBuild/FastSolutionBuildReadme.html

The thing that really bugs me is that VS occasionally freezes for 4-8
seconds in the edtior when all I want to do is update a comment or
something innocuous (rebuilding browse or intellisense info as far as i
can tell for the entire project)
 
CS [Wed, 26 Jan 2005 14:51:31 -0800]:
Also very frusterating is the way the IDE stops responding when doing things
Click to expand...

I heard something about this problem/fix being adjustable in the
"next" version (but I'm not sure how many nexts have come and gone
since then). Until then, this does the trick nicely, and no real
effect on the total times, but a big difference in system response
during.

http://www.codeguru.com/Cpp/V-S/tips/comments.php/c439/?thread=4744
 
CS [Wed, 26 Jan 2005 14:51:31 -0800]:
Also very frusterating is the way the IDE stops responding when
doing things
Click to expand...

I heard something about this problem/fix being adjustable in the
"next" version (but I'm not sure how many nexts have come and gone
since then). Until then, this does the trick nicely, and no real
effect on the total times, but a big difference in system response
during.

http://www.codeguru.com/Cpp/V-S/tips/comments.php/c439/?thread=4744
Click to expand...

Nifty little hack. For the benefit of other readers: The file offset in
vcspawn.exe from vc7.1 is 0x113f.

Now, if there was just such a hack for C# compilations too... but they don't
use vcspawn.

-cd
 
CD- [Thu, 27 Jan 2005 06:52:51 -0800]:
The file offset in >vcspawn.exe from vc7.1 is 0x113f.
Click to expand...

Close, but not quite right. The link has the correct location.
Click to expand...

0x113f is where the entire code snippet referenced in the first posting
begins. 0x1140 is where the single byte to change is located. Sorry for
adding to the confusion - I had to re-read the page several times before I
spotted the file offset - the more apparent offset shown is 0x401d3f which
is clearly not a file offset.

-cd
 
CS [Wed, 26 Jan 2005 14:51:31 -0800]:
Also very frusterating is the way the IDE stops responding when doing
things
Click to expand...

Until then, this does the trick nicely, and no real
effect on the total times, but a big difference in system response
during.
Click to expand...

Thanks for your help. In this case, by IDE I was refering to the integrated
development environment - aka Visual Studio .net 2003 7.1's editor, scroll
bars, find dialog, etc.

It is this IDE that fails to respond during certain portions of the build
phase.

In my product the text editing logic (and associated scroll bar) runs in a
seperate thread than the computation logic. That way while my app is
computing, the user can still use the editor.

I believe the Visual Studio 7.1 .net 2003 developers did not take proper
care to seperate the functionality in their product.

Anyways, my point is that while your tip helps other processes on my system
run with higher priority with respect to the cl.exe and link.exe, it does
not overcome the IDE responsiveness issue.

Thanks,

Chris
 
In my product the text editing logic (and associated scroll bar)
runs in a seperate thread than the computation logic. That way
while my app is computing, the user can still use the editor.

I believe the Visual Studio 7.1 .net 2003 developers did not
take proper care to seperate the functionality in their product.
Click to expand...

Yes, unfortunately in VS2003 IntelliSense did acquire locks on the
primary thread in some scenarios causing such intermittent hangs.
We're working on removing these in VS2005.

Thanks,
 
Tarek Madkour said:
Yes, unfortunately in VS2003 IntelliSense did acquire locks on the
primary thread in some scenarios causing such intermittent hangs.
We're working on removing these in VS2005.
Click to expand...

Hi Tarek,

Thanks so much for your reply! Is there a way to disable IntelliSense?
Would disabling IntelliSense eliminate the primary thread locking issue I
describe?

Thanks,

Chris
 
Thanks so much for your reply! Is there a way to disable
IntelliSense? Would disabling IntelliSense eliminate the primary
thread locking issue I describe?
Click to expand...

One workaround is to delete feacp.dll which would totally disable
intellisense and everything that's based on it (e.g. class view, some
debugger breakpoint validation, some 3rd party plugins).
Alternatively, you could make the .ncb file for the project read-
only.

Thanks,
 
It is true that dependancy checking is unneccesarily slow.
We also found that VC7 has quite different performance characteristics compared to 6.

For instance, if you include a header file that declares lots of constants that are object instances, such as CString constants, the 7.1 compiler is very slow. If you move such a file in a precompiled header, it compiles a lot faster (up to three times on our sources).

I also recently found out that 7.1 has the capability to recompile a dll without rewriting the lib file. VC does this for two of our dlls, not surprisingly the ones which we recreated from scratch in VC7.1. It does not work for vcprojs converted from other visual studio versions. Who knows the secret project setting that affects this? Most of my build time is now spent watching VC rebuild dependent dlls for no reason.

From http://www.developmentnow.com/g/42_2005_1_0_0_46989/I_am_so_frusterated_with_how_slow_MSVC_is.ht

Posted via DevelopmentNow Group
www.developmentnow.com/
www.developmentnow.com
 
Jan de Vaan said:
It is true that dependancy checking is unneccesarily slow.
Click to expand...

Try Fast Solution Build. It's free and it's good.
(Only the linker redirection ones gave us trouble.
Uninstalling the thing and reinstalling it without
linker redirection fixed this.)
We also found that VC7 has quite different performance characteristics compared to 6.

For instance, if you include a header file that declares lots of constants that are object instances, such as CString constants,
the 7.1 compiler is very slow. If you move such a file in a precompiled header, it compiles a lot faster (up to three times on
our sources).
Click to expand...

We ran into this one, too.
What helped was declaring the constants as 'extern'
and compiled the definitions seperately in their
own .cpp file. Parsing const declarations seems to
be a lot faster than parsing const definitions and
this way the definitions have to be parsed only
once.
I also recently found out that 7.1 has the capability to recompile a dll without rewriting the lib file. VC does this for two of
our dlls, not surprisingly the ones which we recreated from scratch in VC7.1. It does not work for vcprojs converted from other
visual studio versions. Who knows the secret project setting that affects this? Most of my build time is now spent watching VC
rebuild dependent dlls for no reason.
Click to expand...

<plug>
Have you looked at IncrediBuild? (www.xoreax.com)
It distributes compilations over the network. We
have recently evaluated it and found it to be very
helpful. On one big project the build times on our
(dedicated 2CPU) build machine went down from about
45mins to about 10mins. One small project I was
recently working on built within 2:30mins instead
of about 8mins. As I was working on some headers
that are included everywhere, I was very happy that
this came together with the evaluation. (It's fun
to watch your project build on a dozen machines
within a fifth of the time.)
We're still undecided how many licenses we will buy.
I am looking forward to the day this is settled.
Just testing it made us all addicted. :)
[...]
Click to expand...


Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 
Back
Top