Slow link times

R

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
 
R

Rudy Ray Moore

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

Ronald Laeremans [MSFT]

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
 
R

Rudy Ray Moore

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)
 
R

Rudy Ray Moore

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)
 
R

Ronald Laeremans [MSFT]

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
 
H

Hendrik Schober

Ronald Laeremans said:
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

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

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

Rudy Ray Moore

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.html#FastSolutionBuild


Hendrik Schober said:
Ronald Laeremans said:
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

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

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

Hendrik Schober

Rudy Ray Moore said:
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.html#FastSolutionBuild

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

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

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

Ronald Laeremans [MSFT]

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 said:
Ronald Laeremans said:
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

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

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

Rudy Ray Moore

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 said:
Rudy Ray Moore said:
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.html#FastSolutionBuild

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

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

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

Hendrik Schober

Rudy Ray Moore said:
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

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

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

Guest

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
 
R

Rudy Ray Moore

Rick,

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

Rudy

Rick Olson said:
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 said:
(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]" <[email protected]> wrote in
message
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
 
R

Ronald Laeremans [MSFT]

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 said:
Rick,

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

Rudy

Rick Olson said:
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
outputs
slower
 
K

Kang Su Gatlin [MS]

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:

(e-mail address removed)


Thanks,

Kang Su Gatlin
Visual C++ Program Manager

--------------------
| From: "Ronald Laeremans [MSFT]" <[email protected]>
| References: <[email protected]>
<[email protected]>
<#[email protected]>
<#[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
| 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
|
| | > Rick,
| >
| > The problem was not resolved. FYI, nobody from MS contacted me.
| >
| > Rudy
| >
| > | > >
| > > 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
| > >
| > > | > > >> 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)
| in
| > message
| > > > | > > >> 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
| > > >> | > > >>>>>> Oh, and I did turn on incremental linking: Project
Settings
| |
| > Linker |
| > > >>> General | Enable Incremental Linking (Yes)
| > > >>> | > > >>>> 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
| > > >>>>>>>>>>>>>>>>>>>>
| >
| >
|
|
|
 
T

Tarek Madkour [MSFT]

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
 
H

Hendrik Schober

Tarek Madkour said:
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.

Schobi

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

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

Tarek Madkour [MSFT]

From: "Hendrik Schober said:
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
 
K

Kang Su Gatlin [MS]

--------------------
| Thread-Topic: Slow link times
| thread-index: AcQjAMT0VEqDGSP1QzCQGq+h5A9Teg==
| X-WN-Post: microsoft.public.dotnet.languages.vc
| From: "=?Utf-8?B?UmljayBPbHNvbg==?=" <[email protected]>
| References: <[email protected]>
<[email protected]>
<#[email protected]>
<#[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
| 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 (e-mail address removed). 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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top