I am so frusterated with how slow MSVC is

[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

[Carl Daniel [VC++ MVP]]

Chris Stankevitz wrote:

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.

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

[Sean Cavanaugh]

Chris Stankevitz wrote:

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

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

http://www.workspacewhiz.com/FastSol...ildReadme.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)

[Carl Daniel [VC++ MVP]]

he*@40th.com wrote:

CS [Wed, 26 Jan 2005 14:51:31 -0800]:

Also very frusterating is the way the IDE stops responding when
doing things

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...9/?thread=4744

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

[Carl Daniel [VC++ MVP]]

he*@40th.com wrote:

CD- [Thu, 27 Jan 2005 06:52:51 -0800]:

The file offset in >vcspawn.exe from vc7.1 is 0x113f.

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

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

[Chris Stankevitz]

"Tarek Madkour [MSFT]" <ta****@online.microsoft.com> wrote in message
news:Xn*****************************@207.46.248.16 ...

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.

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

[Tarek Madkour [MSFT]]

"Chris Stankevitz" <ch******@stankevitz.nospamplease.com> wrote in
news:eZ**************@TK2MSFTNGP10.phx.gbl:

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

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,
--
Tarek Madkour, Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers
no rights.

[Jan de Vaan]

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_2...low_MSVC_is.ht

Posted via DevelopmentNow Group
www.developmentnow.com/
www.developmentnow.com

[Hendrik Schober]

Jan de Vaan <devaan@freelerDOTnl> wrote:

It is true that dependancy checking is unneccesarily slow.
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).
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.
<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. :)
</plug>
[...]

Schobi

--
Sp******@gmx.de 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