Are /clr and /Incremental:YES compatible

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,
setting the switch /clr significantly increased the linking time (ca. 18
min). The linker output shows "/incremental:no /fullbuild", when setting the
switch /test.
The same code linked in less than 1 minute without the /clr switch. Is it
possible to use incremental linking when specifying the /clr switch?
The executable is currently a 15MB monster executable. Would it help to
break up the code into DLL's?

Thank you.
Michael
 
Michael Reinschmiedt said:
Hello,
setting the switch /clr significantly increased the linking time (ca. 18
min). The linker output shows "/incremental:no /fullbuild", when setting
the
switch /test.
The same code linked in less than 1 minute without the /clr switch. Is it
possible to use incremental linking when specifying the /clr switch?
The executable is currently a 15MB monster executable. Would it help to
break up the code into DLL's?

Thank you.
Michael
Click to expand...


Yes, they are compatible but in managed Incremental:yes does not do
anything. We have seen some performance loss while moving to managed but not
a whole lot. Can you add a /link /time switch to your project so that we can
figure out what is taking most of the time. From our experience the max time
during linking is taken during metadata merger.

Thanks,
Kapil
 
Hello Kapil,
the linker output is:
LINK : warning LNK4044: unrecognized option '/link'; ignored
LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO'
specification
Pass 1: Interval #1, time = 770.484s
Pass 2: Interval #2, time = 117.016s
Final: Total time = 887.500s
Final: Total time = 888.516s
created on a machine with VC7.1.3088, processor 3Ghz P4 with 1GB mem.

Thank you for your help.
Michael
 
Michael Reinschmiedt said:
Hello Kapil,
the linker output is:
LINK : warning LNK4044: unrecognized option '/link'; ignored
LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO'
specification
Pass 1: Interval #1, time = 770.484s
Pass 2: Interval #2, time = 117.016s
Final: Total time = 887.500s
Final: Total time = 888.516s
created on a machine with VC7.1.3088, processor 3Ghz P4 with 1GB mem.

Thank you for your help.
Michael
Click to expand...

Hi Michael,
In order to understand what is going on and debug through the problem, I
would need a repro. Would that be possible?

Thanks,
Kapil
 
Kapil Khosla said:
Hi Michael,
In order to understand what is going on and debug through the problem, I
would need a repro. Would that be possible?

Thanks,
Kapil
Click to expand...

Another thing which can be done is to isolate the parts using clr to a
separate dll. Is that a workable solution for you?

Kapil
 
Kapil,
we have about 1600 source files with 2.5 mio. lines of code, hence the
linking time is huge, but not unfair.
If splitting into DLL's would speed up linking, then we would try to do
this. Is it possible/preferable to migrate our old unmanaged code into DLLs
rather than the CLR code? Is there a benefit for having many DLL's rather
than just a few?
Again, thank you for your help.
Michael
 
Michael Reinschmiedt said:
Kapil,
we have about 1600 source files with 2.5 mio. lines of code, hence the
linking time is huge, but not unfair.
If splitting into DLL's would speed up linking, then we would try to do
this. Is it possible/preferable to migrate our old unmanaged code into DLLs
rather than the CLR code? Is there a benefit for having many DLL's rather
than just a few?
Again, thank you for your help.
Michael
Click to expand...


Hello Michael,
The reason for splitting your code into dll's you want to keep the code
executed most often in a separate unit than the one which is not executed
that often. There is no benefit of having many dll's instead of just a few. I
would just rearchitect your code to make the commonly executed parts in
separate units.

Regarding your second question,
Is it possible/preferable to migrate our old unmanaged code into DLLs
rather than the CLR code.
Click to expand...

You can have Dll's in managed code as well. One option is that you can keep
your Dll's native and use C++ interop to provide an interface for your native
dll.

http://msdn2.microsoft.com/library/2x8kf7zx(en-us,vs.80).aspx
This approach requires very little work from your end.

The other option is ofcourse you move your native code to managed code and
then rearchitect and then your applicaiton will be completely managed and you
wont need to use PInvoke or C++ interop.
Thanks,
Kapil
 
Hi Michael,

You can't incrementally link images that have managed code in them and
in general link time for these images is significantly slower than for
all native images.

The recommendation for now is to create smaller DLLs and potentially to
keep compiling the bulk of your code as native and creating a separate
DLL for the pieces that need to be compiled with /CLR.

Ronald Laeremans
Visual C++ team
 
Back
Top