 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / May 2005Are /clr and /Incremental:YES compatible
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 > Hello, > setting the switch /clr significantly increased the linking time (ca. 18 [quoted text clipped - 8 lines] > Thank you. > Michael 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  SignatureThis posting is provided "AS IS" with no warranties, and confers no rights."Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm" 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 > > Hello, > > setting the switch /clr significantly increased the linking time (ca. 18 [quoted text clipped - 17 lines] > Thanks, > Kapil > Hello Kapil, > the linker output is: [quoted text clipped - 31 lines] > > Thanks, > > Kapil 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 > > Hello Kapil, > > the linker output is: [quoted text clipped - 38 lines] > Thanks, > Kapil 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 > > > Hello Kapil, > > > the linker output is: [quoted text clipped - 43 lines] > > Kapil > Kapil, > we have about 1600 source files with 2.5 mio. lines of code, hence the [quoted text clipped - 53 lines] > > > > Kapil 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. 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 > Hello, > setting the switch /clr significantly increased the linking time (ca. 18 [quoted text clipped - 7 lines] > Thank you. > Michael Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.