Slow link times

[Rudy Ray Moore]

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

[Hendrik Schober]

"Tarek Madkour [MSFT]" <ta****@online. microsoft.com> wrote:

From: "Hendrik Schober" <Sp******@gmx.d e> [...]

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

[Rudy Ray Moore]

/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:na fxcwd.lib
Processed /NODEFAULTLIB:li bcd.lib
Processed /NODEFAULTLIB:li bcid.lib
Processed /NODEFAULTLIB:ms vcrt.lib
LINK : LNK6028: file alignment: 512, section alignment: 4096
Processed /NODEFAULTLIB:na fxcwd.lib
Processed /NODEFAULTLIB:li bcd.lib
Processed /NODEFAULTLIB:li bcid.lib
Processed /NODEFAULTLIB:ms vcrt.lib
LINK : LNK6010: library changed; performing full link




"Kang Su Gatlin [MS]" <ka******@micro soft.com> wrote in message
news:1g******** *****@cpmsftngx a06.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******@micros oft.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************ *************** *******@microso ft.com>
<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*******@hotm ail.com> wrote in message
| news:Od******** ******@TK2MSFTN GP11.phx.gbl...
| > Rick,
| >
| > The problem was not resolved. FYI, nobody from MS contacted me.
| >
| > Rudy
| >
| > "Rick Olson" <an*******@disc ussions.microso ft.com> wrote in message
| > news:DC******** *************** ***********@mic rosoft.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*******@hotm ail.com> wrote in message
| > > news:%2******** ********@TK2MSF TNGP11.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******** ********@TK2MSF TNGP10.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*******@hotm ail.com> wrote in message
| > > >> news:e1******** ******@TK2MSFTN GP12.phx.gbl...
| > > >>>>>> Oh, and I did turn on incremental linking: Project
Settings
| |
| > Linker |
| > > >>> General | Enable Incremental Linking (Yes)
| > > >>>>>> "Rudy Ray Moore" <ru*******@hotm ail.com> wrote in message | > > >>> news:uh******** ******@TK2MSFTN GP12.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
| > > >>>>>>>>>>>>>>> >>>>>
| >
| >
|
|
|

[Rudy Ray Moore]

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*******@disc ussions.microso ft.com> wrote in message
news:C5******** *************** ***********@mic rosoft.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