467,220 Members | 1,429 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,220 developers. It's quick & easy.

Slow link times

Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 at linking?

It looks like "Visual Studio .net 2003 7.1 c++" doesn't even do incremental
linking! I make one very minor change in a .cpp from one of my thirty
projects and the whole thing links! (I turned on verbose linking to verify
this.)

Is there something else I need to do to turn on incremental linking?

Rudy
Nov 17 '05 #1
  • viewed: 3484
Share:
22 Replies

Oh, and I did turn on incremental linking: Project Settings | Linker |
General | Enable Incremental Linking (Yes)

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP12.phx.gbl...
Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 at linking?
It looks like "Visual Studio .net 2003 7.1 c++" doesn't even do incremental linking! I make one very minor change in a .cpp from one of my thirty
projects and the whole thing links! (I turned on verbose linking to verify this.)

Is there something else I need to do to turn on incremental linking?

Rudy

Nov 17 '05 #2
Hi Rudy,

Does this project contain any managed code (i.e. code compiled with the CLR
switch)? Incremental linking does not work for managed or mixed images. And
in addition linking them is significantly slower. We are hoping to address
both issues longer term.

If it is a fully native image, we would be interested in taking a look at
why incremental linking doesn't work. Let me know so I can have someone
contact you in that case.

Thanks

Ronald Laeremans
Visual C++ team

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl...

Oh, and I did turn on incremental linking: Project Settings | Linker |
General | Enable Incremental Linking (Yes)

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP12.phx.gbl...
Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 at

linking?

It looks like "Visual Studio .net 2003 7.1 c++" doesn't even do

incremental
linking! I make one very minor change in a .cpp from one of my thirty
projects and the whole thing links! (I turned on verbose linking to

verify
this.)

Is there something else I need to do to turn on incremental linking?

Rudy


Nov 17 '05 #3
Ronald,

I appreciate your interest. We are not using any managed code (it's all
native). I have compiled some statistics and provided some outputs for you
to look at if you are interested. Compile/links are 50-600% slower with 7.1
for regular and incremental builds respectively.

http://www.stankevitz.com/visualstudio/

Rudy (my real email address appears at the bottom of that page)

"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Hi Rudy,

Does this project contain any managed code (i.e. code compiled with the CLR switch)? Incremental linking does not work for managed or mixed images. And in addition linking them is significantly slower. We are hoping to address
both issues longer term.

If it is a fully native image, we would be interested in taking a look at
why incremental linking doesn't work. Let me know so I can have someone
contact you in that case.

Thanks

Ronald Laeremans
Visual C++ team

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl...

Oh, and I did turn on incremental linking: Project Settings | Linker |
General | Enable Incremental Linking (Yes)

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP12.phx.gbl...
Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 at

linking?

It looks like "Visual Studio .net 2003 7.1 c++" doesn't even do

incremental
linking! I make one very minor change in a .cpp from one of my thirty
projects and the whole thing links! (I turned on verbose linking to

verify
this.)

Is there something else I need to do to turn on incremental linking?

Rudy



Nov 17 '05 #4

Ronald,

I appreciate your interest. We are not using any managed code (it's all
native). I have compiled some statistics and provided some outputs for you
to look at if you are interested. Compile/links are 50-600% slower with 7.1
for regular and incremental builds respectively.

http://www.stankevitz.com/visualstudio/

Rudy (real email address appears at the bottom of that page)

"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Hi Rudy,

Does this project contain any managed code (i.e. code compiled with the CLR switch)? Incremental linking does not work for managed or mixed images. And in addition linking them is significantly slower. We are hoping to address
both issues longer term.

If it is a fully native image, we would be interested in taking a look at
why incremental linking doesn't work. Let me know so I can have someone
contact you in that case.

Thanks

Ronald Laeremans
Visual C++ team

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl...

Oh, and I did turn on incremental linking: Project Settings | Linker |
General | Enable Incremental Linking (Yes)

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP12.phx.gbl...
Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 at

linking?

It looks like "Visual Studio .net 2003 7.1 c++" doesn't even do

incremental
linking! I make one very minor change in a .cpp from one of my thirty
projects and the whole thing links! (I turned on verbose linking to

verify
this.)

Is there something else I need to do to turn on incremental linking?

Rudy



Nov 17 '05 #5
Hi Rudy,

Thanks for putting that page together. I asked the folks from the IDE team
(for the rebuild issue and the other IDE comments) and the linker team to
take a look and contact you. In the unlikely case that doesn't happen over
the next week or so, please ping me (first name plus first letter of last
name at microsoft dot com).

Ronald Laeremans

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Ronald,

I appreciate your interest. We are not using any managed code (it's all
native). I have compiled some statistics and provided some outputs for you to look at if you are interested. Compile/links are 50-600% slower with 7.1 for regular and incremental builds respectively.

http://www.stankevitz.com/visualstudio/

Rudy (real email address appears at the bottom of that page)

"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Hi Rudy,

Does this project contain any managed code (i.e. code compiled with the

CLR
switch)? Incremental linking does not work for managed or mixed images.

And
in addition linking them is significantly slower. We are hoping to address both issues longer term.

If it is a fully native image, we would be interested in taking a look at why incremental linking doesn't work. Let me know so I can have someone
contact you in that case.

Thanks

Ronald Laeremans
Visual C++ team

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl...

Oh, and I did turn on incremental linking: Project Settings | Linker |
General | Enable Incremental Linking (Yes)

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP12.phx.gbl...
> Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 at
linking?
>
> It looks like "Visual Studio .net 2003 7.1 c++" doesn't even do
incremental
> linking! I make one very minor change in a .cpp from one of my thirty > projects and the whole thing links! (I turned on verbose linking to
verify
> this.)
>
> Is there something else I need to do to turn on incremental linking?
>
> Rudy
>
>



Nov 17 '05 #6
Ronald Laeremans [MSFT] <ro*****@online.microsoft.com> wrote:
Hi Rudy,

Thanks for putting that page together. I asked the folks from the IDE team
(for the rebuild issue and the other IDE comments) and the linker team to
take a look and contact you. [...]
Ronald, I didn't think this was something
special. When we took a (pure native)
project from VC6 to VC7.1, the time for a
rebuild went up from about 15min to about
60min. (And this is Debug builds with /Od.)
The time needed to re-compile individual
files went up just the same.

Can we expect Whidbey to get better with
this? We are loosing a lot of time waiting
for the compiler.
Ronald Laeremans
[...]


Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
Nov 17 '05 #7

I found a wonderful solution to the problem. It's unfortunate that "VS7.1
c++ .net 2003" is slower thatn VC++6 at this, but this solution makes the
new VS act like the old:

Install this free open-source program:
http://workspacewhiz.com/OtherAddins...tSolutionBuild
"Hendrik Schober" <Sp******@gmx.de> wrote in message
news:ug**************@TK2MSFTNGP10.phx.gbl...
Ronald Laeremans [MSFT] <ro*****@online.microsoft.com> wrote:
Hi Rudy,

Thanks for putting that page together. I asked the folks from the IDE team (for the rebuild issue and the other IDE comments) and the linker team to take a look and contact you. [...]


Ronald, I didn't think this was something
special. When we took a (pure native)
project from VC6 to VC7.1, the time for a
rebuild went up from about 15min to about
60min. (And this is Debug builds with /Od.)
The time needed to re-compile individual
files went up just the same.

Can we expect Whidbey to get better with
this? We are loosing a lot of time waiting
for the compiler.
Ronald Laeremans
[...]


Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

Nov 17 '05 #8
Rudy Ray Moore <ru*******@hotmail.com> wrote:
I found a wonderful solution to the problem. It's unfortunate that "VS7.1
c++ .net 2003" is slower thatn VC++6 at this, but this solution makes the
new VS act like the old:

Install this free open-source program:
http://workspacewhiz.com/OtherAddins...tSolutionBuild
IIUC, this only helps with dependency
checks. Our main problem is very slow
compilation and linking. (Dependency
checking takes 20sec, a full build
takes ~1h.)
Thanks anyway.
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
Nov 17 '05 #9
Hi Hendrik,

A 300% slowdown is definitely not in the expected, or acceptable range,
please contact me privately over email (my contact info, hopefully in a non
spam collection friendly way, is in an earlier message in this thread) so we
can get a repro from you to analyze.

Ronald

"Hendrik Schober" <Sp******@gmx.de> wrote in message
news:ug**************@TK2MSFTNGP10.phx.gbl...
Ronald Laeremans [MSFT] <ro*****@online.microsoft.com> wrote:
Hi Rudy,

Thanks for putting that page together. I asked the folks from the IDE team (for the rebuild issue and the other IDE comments) and the linker team to take a look and contact you. [...]


Ronald, I didn't think this was something
special. When we took a (pure native)
project from VC6 to VC7.1, the time for a
rebuild went up from about 15min to about
60min. (And this is Debug builds with /Od.)
The time needed to re-compile individual
files went up just the same.

Can we expect Whidbey to get better with
this? We are loosing a lot of time waiting
for the compiler.
Ronald Laeremans
[...]


Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

Nov 17 '05 #10
Nope. It fixes long links for me. Before installing FSB, an "incremental"
link (one after I just made a change to one of a thousand .cpp files) took 3
minutes. Now it takes about 3 seconds.

Rudy

"Hendrik Schober" <Sp******@gmx.de> wrote in message
news:eY**************@tk2msftngp13.phx.gbl...
Rudy Ray Moore <ru*******@hotmail.com> wrote:
I found a wonderful solution to the problem. It's unfortunate that "VS7.1 c++ .net 2003" is slower thatn VC++6 at this, but this solution makes the new VS act like the old:

Install this free open-source program:
http://workspacewhiz.com/OtherAddins...tSolutionBuild


IIUC, this only helps with dependency
checks. Our main problem is very slow
compilation and linking. (Dependency
checking takes 20sec, a full build
takes ~1h.)
Thanks anyway.
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

Nov 17 '05 #11
Rudy Ray Moore <ru*******@hotmail.com> wrote:
Nope. It fixes long links for me. Before installing FSB, an "incremental"
link (one after I just made a change to one of a thousand .cpp files) took 3
minutes. Now it takes about 3 seconds.
I see. Of course, link times after
changing one .cpp file are too long.
I probably didn't notice that because
1) a full build is so incredably bad
that everything else kind of fades
compared to it and 2) I got into the
habit of explicitly telling the IDE
to only build the current project
(and not to look at all the libs it
depends on).
You are right, when one looks at it
this way, one would think _this_ is
what an IDE is for...
I'll check the plugin when I find the
time next week.
Rudy
[...]


Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
Nov 17 '05 #12

Hi Ronald

I have been experiencing the same link behaviour that Rudy describes. Was the problem resolved and if so, was there a solution or workaround that could be shared with the rest of us

Thanks for the help

--Rick Olso

----- Ronald Laeremans [MSFT] wrote: ----

Hi Rudy

Thanks for putting that page together. I asked the folks from the IDE tea
(for the rebuild issue and the other IDE comments) and the linker team t
take a look and contact you. In the unlikely case that doesn't happen ove
the next week or so, please ping me (first name plus first letter of las
name at microsoft dot com)

Ronald Laereman

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in messag
news:%2****************@TK2MSFTNGP11.phx.gbl..
Ronald
I appreciate your interest. We are not using any managed code (it's al native). I have compiled some statistics and provided some outputs fo

yo to look at if you are interested. Compile/links are 50-600% slower wit 7. for regular and incremental builds respectively
http://www.stankevitz.com/visualstudio
Rudy (real email address appears at the bottom of that page
"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in messag

news:%2****************@TK2MSFTNGP10.phx.gbl..
Hi Rudy
Does this project contain any managed code (i.e. code compiled with th CL
switch)? Incremental linking does not work for managed or mixed images

An
in addition linking them is significantly slower. We are hoping t

addres both issues longer term
If it is a fully native image, we would be interested in taking a loo a
why incremental linking doesn't work. Let me know so I can have someon
contact you in that case
Thank
Ronald Laereman

Visual C++ tea
"Rudy Ray Moore" <ru*******@hotmail.com> wrote in messag

news:e1**************@TK2MSFTNGP12.phx.gbl..
>> Oh, and I did turn on incremental linking: Project Settings | Linker
General | Enable Incremental Linking (Yes
>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in messag
news:uh**************@TK2MSFTNGP12.phx.gbl..
Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 a
linking
>>>> It looks like "Visual Studio .net 2003 7.1 c++" doesn't even d
incrementa
linking! I make one very minor change in a .cpp from one of m

thirt projects and the whole thing links! (I turned on verbose linking t
verif
this.
>>>> Is there something else I need to do to turn on incremental linking
>>>> Rud
>>>>>>>>>>>>>>>>

Nov 17 '05 #13
Rick,

The problem was not resolved. FYI, nobody from MS contacted me.

Rudy

"Rick Olson" <an*******@discussions.microsoft.com> wrote in message
news:DC**********************************@microsof t.com...

Hi Ronald,

I have been experiencing the same link behaviour that Rudy describes. Was the problem resolved and if so, was there a solution or workaround that
could be shared with the rest of us?
Thanks for the help,

--Rick Olson

----- Ronald Laeremans [MSFT] wrote: -----

Hi Rudy,

Thanks for putting that page together. I asked the folks from the IDE team (for the rebuild issue and the other IDE comments) and the linker team to take a look and contact you. In the unlikely case that doesn't happen over the next week or so, please ping me (first name plus first letter of last name at microsoft dot com).

Ronald Laeremans

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
>> Ronald,
>> I appreciate your interest. We are not using any managed code (it's all
> native). I have compiled some statistics and provided some outputs for
you
> to look at if you are interested. Compile/links are 50-600% slower with
7.1
> for regular and incremental builds respectively.
>> http://www.stankevitz.com/visualstudio/
>> Rudy (real email address appears at the bottom of that page)
>> "Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in
message > news:%2****************@TK2MSFTNGP10.phx.gbl...
>> Hi Rudy,
>>>> Does this project contain any managed code (i.e. code compiled
with the > CLR
>> switch)? Incremental linking does not work for managed or mixed
images. > And
>> in addition linking them is significantly slower. We are hoping to

address >> both issues longer term.
>>>> If it is a fully native image, we would be interested in taking
a look at >> why incremental linking doesn't work. Let me know so I can have
someone >> contact you in that case.
>>>> Thanks
>>>> Ronald Laeremans
>> Visual C++ team
>>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
>> news:e1**************@TK2MSFTNGP12.phx.gbl...
>>>>>> Oh, and I did turn on incremental linking: Project Settings | Linker | >>> General | Enable Incremental Linking (Yes)
>>>>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
>>> news:uh**************@TK2MSFTNGP12.phx.gbl...
>>>> Why is "Visual Studio .net 2003 7.1 c++" so much slower than VS6 at >>> linking?
>>>>>>>> It looks like "Visual Studio .net 2003 7.1 c++" doesn't even do >>> incremental
>>>> linking! I make one very minor change in a .cpp from one of my

thirty >>>> projects and the whole thing links! (I turned on verbose linking to >>> verify
>>>> this.)
>>>>>>>> Is there something else I need to do to turn on incremental linking? >>>>>>>> Rudy
>>>>>>>>>>>>>>>>>>>>

Nov 17 '05 #14
I pinged the 2 teams. You should be contacted shortly. Send me an email (the
obvious transformation of my posting alias will give you my email address)
if you haven't been contacted in the next few days.

Sorry for the delay.

Ronald

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:Od**************@TK2MSFTNGP11.phx.gbl...
Rick,

The problem was not resolved. FYI, nobody from MS contacted me.

Rudy

"Rick Olson" <an*******@discussions.microsoft.com> wrote in message
news:DC**********************************@microsof t.com...

Hi Ronald,

I have been experiencing the same link behaviour that Rudy describes. Was
the problem resolved and if so, was there a solution or workaround that
could be shared with the rest of us?

Thanks for the help,

--Rick Olson

----- Ronald Laeremans [MSFT] wrote: -----

Hi Rudy,

Thanks for putting that page together. I asked the folks from the IDE
team
(for the rebuild issue and the other IDE comments) and the linker team to
take a look and contact you. In the unlikely case that doesn't

happen over
the next week or so, please ping me (first name plus first letter
of last
name at microsoft dot com).

Ronald Laeremans

"Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
>> Ronald,
>> I appreciate your interest. We are not using any managed code
(it's all > native). I have compiled some statistics and provided some
outputs for
you
> to look at if you are interested. Compile/links are 50-600%
slower with
7.1
> for regular and incremental builds respectively.
>> http://www.stankevitz.com/visualstudio/
>> Rudy (real email address appears at the bottom of that page)
>> "Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote
in message > news:%2****************@TK2MSFTNGP10.phx.gbl...
>> Hi Rudy,
>>>> Does this project contain any managed code (i.e. code compiled with the > CLR
>> switch)? Incremental linking does not work for managed or mixed images. > And
>> in addition linking them is significantly slower. We are hoping
to address
>> both issues longer term.
>>>> If it is a fully native image, we would be interested in
taking
a look
at
>> why incremental linking doesn't work. Let me know so I can have
someone >> contact you in that case.
>>>> Thanks
>>>> Ronald Laeremans
>> Visual C++ team
>>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
>> news:e1**************@TK2MSFTNGP12.phx.gbl...
>>>>>> Oh, and I did turn on incremental linking: Project Settings
| Linker | >>> General | Enable Incremental Linking (Yes)
>>>>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
>>> news:uh**************@TK2MSFTNGP12.phx.gbl...
>>>> Why is "Visual Studio .net 2003 7.1 c++" so much slower than
VS6
at >>> linking?
>>>>>>>> It looks like "Visual Studio .net 2003 7.1 c++" doesn't
even
do >>> incremental
>>>> linking! I make one very minor change in a .cpp from one of
my thirty
>>>> projects and the whole thing links! (I turned on verbose
linking to >>> verify
>>>> this.)
>>>>>>>> Is there something else I need to do to turn on
incremental linking? >>>>>>>> Rudy
>>>>>>>>>>>>>>>>>>>>


Nov 17 '05 #15
Hi Rudy, we are definitely interested in a link-repro and/or the output
data that you currently have. Also use /time to get per pass timings.

Also could you ensure that you're linking 7.1 code, with the 7.1 linker.
If you're linking 6.0 code with the 7.1 linker, this can slow things down.

You send this info directly to me at:

ka******@microsoft.com
Thanks,

Kang Su Gatlin
Visual C++ Program Manager

--------------------
| From: "Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com>
| References: <uh**************@TK2MSFTNGP12.phx.gbl>
<e1**************@TK2MSFTNGP12.phx.gbl>
<#F**************@TK2MSFTNGP10.phx.gbl>
<#Q**************@TK2MSFTNGP11.phx.gbl>
<uA**************@TK2MSFTNGP10.phx.gbl>
<DC**********************************@microsoft.co m>
<Od**************@TK2MSFTNGP11.phx.gbl>
| Subject: Re: Slow link times
| Date: Mon, 12 Apr 2004 13:03:06 -0700

| I pinged the 2 teams. You should be contacted shortly. Send me an email
(the
| obvious transformation of my posting alias will give you my email address)
| if you haven't been contacted in the next few days.
|
| Sorry for the delay.
|
| Ronald
|
| "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
| news:Od**************@TK2MSFTNGP11.phx.gbl...
| > Rick,
| >
| > The problem was not resolved. FYI, nobody from MS contacted me.
| >
| > Rudy
| >
| > "Rick Olson" <an*******@discussions.microsoft.com> wrote in message
| > news:DC**********************************@microsof t.com...
| > >
| > > Hi Ronald,
| > >
| > > I have been experiencing the same link behaviour that Rudy describes.
| Was
| > the problem resolved and if so, was there a solution or workaround that
| > could be shared with the rest of us?
| > >
| > > Thanks for the help,
| > >
| > > --Rick Olson
| > >
| > > ----- Ronald Laeremans [MSFT] wrote: -----
| > >
| > > Hi Rudy,
| > >
| > > Thanks for putting that page together. I asked the folks from the
| IDE
| > team
| > > (for the rebuild issue and the other IDE comments) and the linker
| > team to
| > > take a look and contact you. In the unlikely case that doesn't
| happen
| > over
| > > the next week or so, please ping me (first name plus first letter
| of
| > last
| > > name at microsoft dot com).
| > >
| > > Ronald Laeremans
| > >
| > > "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
| > > news:%2****************@TK2MSFTNGP11.phx.gbl...
| > > >> Ronald,
| > > >> I appreciate your interest. We are not using any managed code
| > (it's all
| > > > native). I have compiled some statistics and provided some
| outputs
| > for
| > > you
| > > > to look at if you are interested. Compile/links are 50-600%
| slower
| > with
| > > 7.1
| > > > for regular and incremental builds respectively.
| > > >> http://www.stankevitz.com/visualstudio/
| > > >> Rudy (real email address appears at the bottom of that page)
| > > >> "Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote
| in
| > message
| > > > news:%2****************@TK2MSFTNGP10.phx.gbl...
| > > >> Hi Rudy,
| > > >>>> Does this project contain any managed code (i.e. code
compiled
| > with the
| > > > CLR
| > > >> switch)? Incremental linking does not work for managed or
mixed
| > images.
| > > > And
| > > >> in addition linking them is significantly slower. We are
hoping
| to
| > > address
| > > >> both issues longer term.
| > > >>>> If it is a fully native image, we would be interested in
| taking
| > a look
| > > at
| > > >> why incremental linking doesn't work. Let me know so I can
have
| > someone
| > > >> contact you in that case.
| > > >>>> Thanks
| > > >>>> Ronald Laeremans
| > > >> Visual C++ team
| > > >>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
| > > >> news:e1**************@TK2MSFTNGP12.phx.gbl...
| > > >>>>>> Oh, and I did turn on incremental linking: Project
Settings
| |
| > Linker |
| > > >>> General | Enable Incremental Linking (Yes)
| > > >>>>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
| > > >>> news:uh**************@TK2MSFTNGP12.phx.gbl...
| > > >>>> Why is "Visual Studio .net 2003 7.1 c++" so much slower than
| VS6
| > at
| > > >>> linking?
| > > >>>>>>>> It looks like "Visual Studio .net 2003 7.1 c++" doesn't
| even
| > do
| > > >>> incremental
| > > >>>> linking! I make one very minor change in a .cpp from one of
| my
| > > thirty
| > > >>>> projects and the whole thing links! (I turned on verbose
| > linking to
| > > >>> verify
| > > >>>> this.)
| > > >>>>>>>> Is there something else I need to do to turn on
| incremental
| > linking?
| > > >>>>>>>> Rudy
| > > >>>>>>>>>>>>>>>>>>>>
| >
| >
|
|
|

Nov 17 '05 #16
Rudy - as an aside, these are some comments on the IDE issues you mentioned
in the referenced web page.

* IDE hangs during towards the end of compilation
Our QA team was not able to reproduce this problem in our labs. Can you
post a call stack of what the IDE is doing during this hang?

* Build from the IDE is slow due to time lost in dependency checking
This is a bad bug. We fixed this in our upcoming release (now in Alpha).

* Projects build in reverse alphabetical order
That is true. But why is this a problem? This only happens when there are
no dependencies between projects. If there are dependencies, we build in
the correct order. Unrelated projects are built in some pseudo-random order
(which happens to be the reverse alphabetical order).

Thanks
--
Tarek Madkour, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

Nov 17 '05 #17
"Tarek Madkour [MSFT]" <ta****@online.microsoft.com> wrote:
Rudy - as an aside, these are some comments on the IDE issues you mentioned
in the referenced web page.

* IDE hangs during towards the end of compilation
Our QA team was not able to reproduce this problem in our labs. Can you
post a call stack of what the IDE is doing during this hang?
I believe it's the code generation phase when the
"vc.exe" process just uses all available processor
resources. This not only blocks the IDE, but also
everything else on the machine.
I got into the habit of setting down the priority
of the "devenv.exe" process and setting up the
priority of "msimm.exe" first thing in the morning
in order to be able to read news while the compiler
is busy.
[...]
* Projects build in reverse alphabetical order
That is true. But why is this a problem? This only happens when there are
no dependencies between projects. If there are dependencies, we build in
the correct order. Unrelated projects are built in some pseudo-random order
(which happens to be the reverse alphabetical order).
Actually, I want to be able to specify the order in
which the projects appear in the Solution Explorer
and have the IDE buils them in exactly this order.
And I want to be able to do the same with each file
within the folders of a project.
The reason for this is, that often I have the
situation that some project/file is more fundamental
or uses some stuff in a mor fundamental way than
another project/file even though the latter doesn't
really depend on the former. If I could specify
which one is supposed to compile first, I might find
compile errors earlier.
For example, it may happen that I change a header,
hit F7, a couple of projects get compiled that all
depend on that header, and only in the last project
to compile a compile error shows up. Since I know the
intrinsics of my code/projects pretty good, if I can
specifiy the order of compilation I can do it in a
way that makes this scenario unlikely.
Thanks


Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
Nov 17 '05 #18
> From: "Hendrik Schober" <Sp******@gmx.de>
Rudy - as an aside, these are some comments on the IDE issues you mentioned in the referenced web page.

* IDE hangs during towards the end of compilation
Our QA team was not able to reproduce this problem in our labs. Can you
post a call stack of what the IDE is doing during this hang?


I believe it's the code generation phase when the
"vc.exe" process just uses all available processor
resources. This not only blocks the IDE, but also
everything else on the machine.
I got into the habit of setting down the priority
of the "devenv.exe" process and setting up the
priority of "msimm.exe" first thing in the morning
in order to be able to read news while the compiler
is busy.


I think you mistyped vc.exe (I don't know of one). Who was consuming most
cycles: devenv.exe, vcspawn.exe or cl.exe?

If it's cl.exe, then it's a good thing :) If it's devenv or vcspawn then we
should take a look at that. A callstack would really help here.
[...]
* Projects build in reverse alphabetical order
That is true. But why is this a problem? This only happens when there are no dependencies between projects. If there are dependencies, we build in
the correct order. Unrelated projects are built in some pseudo-random order (which happens to be the reverse alphabetical order).


Actually, I want to be able to specify the order in
which the projects appear in the Solution Explorer
and have the IDE buils them in exactly this order.
And I want to be able to do the same with each file
within the folders of a project.
The reason for this is, that often I have the
situation that some project/file is more fundamental
or uses some stuff in a mor fundamental way than
another project/file even though the latter doesn't
really depend on the former. If I could specify
which one is supposed to compile first, I might find
compile errors earlier.
For example, it may happen that I change a header,
hit F7, a couple of projects get compiled that all
depend on that header, and only in the last project
to compile a compile error shows up. Since I know the
intrinsics of my code/projects pretty good, if I can
specifiy the order of compilation I can do it in a
way that makes this scenario unlikely.


That proves to me once more that there is a customer out there for any
scenario that I can or cannot think of. I must admit that this usage
scenario never crossed my mind :)

In Whidbey, we are adding a new feature to allow you to logically organize
your projects into folders in the solution. It will not help with your
specific scenario but it will help you visually order projects in a
solution.

Thanks
--
Tarek Madkour, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

Nov 17 '05 #19

--------------------
| Thread-Topic: Slow link times
| thread-index: AcQjAMT0VEqDGSP1QzCQGq+h5A9Teg==
| X-WN-Post: microsoft.public.dotnet.languages.vc
| From: "=?Utf-8?B?UmljayBPbHNvbg==?=" <an*******@discussions.microsoft.com>
| References: <uh**************@TK2MSFTNGP12.phx.gbl>
<e1**************@TK2MSFTNGP12.phx.gbl>
<#F**************@TK2MSFTNGP10.phx.gbl>
<#Q**************@TK2MSFTNGP11.phx.gbl>
<uA**************@TK2MSFTNGP10.phx.gbl>
<DC**********************************@microsoft.co m>
<Od**************@TK2MSFTNGP11.phx.gbl>
<Oa**************@TK2MSFTNGP10.phx.gbl>
<XI**************@cpmsftngxa06.phx.gbl>
| Subject: Re: Slow link times
| Date: Thu, 15 Apr 2004 08:46:08 -0700

| Hi again gang,

Just to add some more information to this, I ran some tests between VS 6
(sp5) and Visual Studio.Net (7.1.3088). My project is all C++, native, no
managed code. With incremental linking enabled in both my projects, the
link times are incredibly different between the two VS versions. If I
add/remove a blank line from a file and re-build, VS 6 takes about 2-3
seconds to compile/link. VS.Net for the same file takes about 38 seconds.
I turned on VERBOSE output for the linker and it sure appears that the
VS.Net version is NOT doing an incremental link. It is searching all the
libraries to resolve references. The verbose output of VS 6 is about 3
lines long and says something about Start Pass2, lists the object
corresponding to the source file I changed, and End of Pass 2.

I can provide any information to any of you at Microsoft to help resolve
this problem (project files, link outputs, etc.) This has been driving me
nuts since we moved over to VS.Net.

Thanks for any help you can provide!

--Rick Olson

Hi Rick,

If you have a project that we could use, that would be great. Feel free to
email it to me at ka******@microsoft.com. Put "Slow link times" in the
title.

What you may want to do first is to add the "/test" option to the linker
and see what it says regarding why you aren't getting an incremenal link.

Thanks!

Kang Su Gatlin
Visual C++ Program Manager
Nov 17 '05 #20
"Tarek Madkour [MSFT]" <ta****@online.microsoft.com> wrote:
From: "Hendrik Schober" <Sp******@gmx.de> [...]
I believe it's the code generation phase when the
"vc.exe" process just uses all available processor
resources. This not only blocks the IDE, but also
everything else on the machine.

[...]

I think you mistyped vc.exe (I don't know of one). Who was consuming most
cycles: devenv.exe, vcspawn.exe or cl.exe?


Ooops, sorry. "cl.exe".
If it's cl.exe, then it's a good thing :) If it's devenv or vcspawn then we
should take a look at that. A callstack would really help here.
I don't think it's a good thing when it takes
_all_ processor time (unless it's forced to
collaborate by setting down its priority). At
least, VC6 didn't do this. Neither do other
compilers I have access to.
[...]

Actually, I want to be able to specify the order in
which the projects appear in the Solution Explorer
and have the IDE buils them in exactly this order.
And I want to be able to do the same with each file
within the folders of a project.
[...]

That proves to me once more that there is a customer out there for any
scenario that I can or cannot think of. I must admit that this usage
scenario never crossed my mind :)


Oh yeah, perhaps I'm just another kind of
weirdo... :o>
If you either
o implemented two-phase lookup or
o decreased turn-around times for the
scenario where I change a header and have
to re-compile dozens or hundreds of files
by a factor of about ten :^>
it wouldn't be so bad anymore. However, as it
is, I often think very hard in order to find
the file that is most likely to trigger an
error from the changes I made and compile this
file manually, before I have the whole solution
built. (If the IDE obeyed the order I put the
stuff, I would only have to think once.)
Assume you have a project with some template
stuff in it. Only one cpp file will instanciate
these templates, but all others need to see
the declarations:

+-prj
+-TemplStuff
| +-templ.h
| +-templ.cpp
+-TemplUser1
| +-templuser1.cpp
+-TemplUser2
| +-templuser2.cpp
+-TemplUser3
+-templuser3.cpp

Now, only "templ.cpp" will instanciate the
templates and therefor triggers any errors. If
the IDE would just compile everythign in the
order I put it, that would be fine. But as it
is, it might decide to compile everything else
first, so I find the error in the last file it
compiles, and have to go back and compile
everything else again.
In Whidbey, we are adding a new feature to allow you to logically organize
your projects into folders in the solution. It will not help with your
specific scenario but it will help you visually order projects in a
solution.
Oh my, it is _especially_ annoying if I'm able
to put everything neatly into the right order
and _still_ the IDE couldn't care less... <g>
Thanks


Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
Nov 17 '05 #21
/test tells me the reason for the full link. Apparently a "library
changed." Which library changed to cause a full link? (see output below)

Thanks,

Rudy

Linking...
Processed /NODEFAULTLIB:nafxcwd.lib
Processed /NODEFAULTLIB:libcd.lib
Processed /NODEFAULTLIB:libcid.lib
Processed /NODEFAULTLIB:msvcrt.lib
LINK : LNK6028: file alignment: 512, section alignment: 4096
Processed /NODEFAULTLIB:nafxcwd.lib
Processed /NODEFAULTLIB:libcd.lib
Processed /NODEFAULTLIB:libcid.lib
Processed /NODEFAULTLIB:msvcrt.lib
LINK : LNK6010: library changed; performing full link




"Kang Su Gatlin [MS]" <ka******@microsoft.com> wrote in message
news:1g*************@cpmsftngxa06.phx.gbl...
Hi Rudy, we are definitely interested in a link-repro and/or the output
data that you currently have. Also use /time to get per pass timings.

Also could you ensure that you're linking 7.1 code, with the 7.1 linker.
If you're linking 6.0 code with the 7.1 linker, this can slow things down.

You send this info directly to me at:

ka******@microsoft.com
Thanks,

Kang Su Gatlin
Visual C++ Program Manager

--------------------
| From: "Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com>
| References: <uh**************@TK2MSFTNGP12.phx.gbl>
<e1**************@TK2MSFTNGP12.phx.gbl>
<#F**************@TK2MSFTNGP10.phx.gbl>
<#Q**************@TK2MSFTNGP11.phx.gbl>
<uA**************@TK2MSFTNGP10.phx.gbl>
<DC**********************************@microsoft.co m>
<Od**************@TK2MSFTNGP11.phx.gbl>
| Subject: Re: Slow link times
| Date: Mon, 12 Apr 2004 13:03:06 -0700

| I pinged the 2 teams. You should be contacted shortly. Send me an email
(the
| obvious transformation of my posting alias will give you my email address) | if you haven't been contacted in the next few days.
|
| Sorry for the delay.
|
| Ronald
|
| "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
| news:Od**************@TK2MSFTNGP11.phx.gbl...
| > Rick,
| >
| > The problem was not resolved. FYI, nobody from MS contacted me.
| >
| > Rudy
| >
| > "Rick Olson" <an*******@discussions.microsoft.com> wrote in message
| > news:DC**********************************@microsof t.com...
| > >
| > > Hi Ronald,
| > >
| > > I have been experiencing the same link behaviour that Rudy describes. | Was
| > the problem resolved and if so, was there a solution or workaround that | > could be shared with the rest of us?
| > >
| > > Thanks for the help,
| > >
| > > --Rick Olson
| > >
| > > ----- Ronald Laeremans [MSFT] wrote: -----
| > >
| > > Hi Rudy,
| > >
| > > Thanks for putting that page together. I asked the folks from the | IDE
| > team
| > > (for the rebuild issue and the other IDE comments) and the linker | > team to
| > > take a look and contact you. In the unlikely case that doesn't
| happen
| > over
| > > the next week or so, please ping me (first name plus first letter | of
| > last
| > > name at microsoft dot com).
| > >
| > > Ronald Laeremans
| > >
| > > "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
| > > news:%2****************@TK2MSFTNGP11.phx.gbl...
| > > >> Ronald,
| > > >> I appreciate your interest. We are not using any managed code | > (it's all
| > > > native). I have compiled some statistics and provided some
| outputs
| > for
| > > you
| > > > to look at if you are interested. Compile/links are 50-600%
| slower
| > with
| > > 7.1
| > > > for regular and incremental builds respectively.
| > > >> http://www.stankevitz.com/visualstudio/
| > > >> Rudy (real email address appears at the bottom of that page)
| > > >> "Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote | in
| > message
| > > > news:%2****************@TK2MSFTNGP10.phx.gbl...
| > > >> Hi Rudy,
| > > >>>> Does this project contain any managed code (i.e. code
compiled
| > with the
| > > > CLR
| > > >> switch)? Incremental linking does not work for managed or
mixed
| > images.
| > > > And
| > > >> in addition linking them is significantly slower. We are
hoping
| to
| > > address
| > > >> both issues longer term.
| > > >>>> If it is a fully native image, we would be interested in
| taking
| > a look
| > > at
| > > >> why incremental linking doesn't work. Let me know so I can
have
| > someone
| > > >> contact you in that case.
| > > >>>> Thanks
| > > >>>> Ronald Laeremans
| > > >> Visual C++ team
| > > >>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message
| > > >> news:e1**************@TK2MSFTNGP12.phx.gbl...
| > > >>>>>> Oh, and I did turn on incremental linking: Project
Settings
| |
| > Linker |
| > > >>> General | Enable Incremental Linking (Yes)
| > > >>>>>> "Rudy Ray Moore" <ru*******@hotmail.com> wrote in message | > > >>> news:uh**************@TK2MSFTNGP12.phx.gbl...
| > > >>>> Why is "Visual Studio .net 2003 7.1 c++" so much slower than | VS6
| > at
| > > >>> linking?
| > > >>>>>>>> It looks like "Visual Studio .net 2003 7.1 c++" doesn't | even
| > do
| > > >>> incremental
| > > >>>> linking! I make one very minor change in a .cpp from one of | my
| > > thirty
| > > >>>> projects and the whole thing links! (I turned on verbose
| > linking to
| > > >>> verify
| > > >>>> this.)
| > > >>>>>>>> Is there something else I need to do to turn on
| incremental
| > linking?
| > > >>>>>>>> Rudy
| > > >>>>>>>>>>>>>>>>>>>>
| >
| >
|
|
|

Nov 17 '05 #22
Rick,

My app always does a full link.

Specifying "/test" to the linker tells you the reson for the full link.
Here's the reason given for the full link. For me, MSVC reports the
following reason:

LINK : LNK6010: library changed; performing full link

What does it say for you?

Rudy

"Rick Olson" <an*******@discussions.microsoft.com> wrote in message
news:C5**********************************@microsof t.com...
Hi again gang,

Just to add some more information to this, I ran some tests between VS 6 (sp5) and Visual Studio.Net (7.1.3088). My project is all C++, native, no
managed code. With incremental linking enabled in both my projects, the
link times are incredibly different between the two VS versions. If I
add/remove a blank line from a file and re-build, VS 6 takes about 2-3
seconds to compile/link. VS.Net for the same file takes about 38 seconds.
I turned on VERBOSE output for the linker and it sure appears that the
VS.Net version is NOT doing an incremental link. It is searching all the
libraries to resolve references. The verbose output of VS 6 is about 3
lines long and says something about Start Pass2, lists the object
corresponding to the source file I changed, and End of Pass 2.
I can provide any information to any of you at Microsoft to help resolve this problem (project files, link outputs, etc.) This has been driving me
nuts since we moved over to VS.Net.
Thanks for any help you can provide!

--Rick Olson

Nov 17 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by GSpiggle | last post: by
8 posts views Thread by BlueBall | last post: by
reply views Thread by roiavidan@gmail.com | last post: by
7 posts views Thread by =?Utf-8?B?QWtlcmx1bmQ=?= | last post: by
9 posts views Thread by SAL | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.