Re: REPOST: extremely long link times
From: Steve McLellan (sjm.NOSPAM)
Date: 07/27/04
- Next message: Fireangel: "RE: disabled breakpoints in a VB class"
- Previous message: William DePalo [MVP VC++]: "Re: PE Manipulation (???)"
- In reply to: Fireangel: "RE: REPOST: extremely long link times"
- Next in thread: doug mansell: "Re: REPOST: extremely long link times"
- Reply: doug mansell: "Re: REPOST: extremely long link times"
- Reply: TOM: "Re: REPOST: extremely long link times"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 27 Jul 2004 18:21:02 +0100
Hi,
1. Nope, and it's linking that's the problem - compiling's generally very
fast. In any case, it's not getting anywhere near maxing the processor so
it's not the workload slowing it down.
2. It is only recompiling the minimum but incremental linking apparently
doesn't work under /clr.
3. I am now wondering whether it'd be better to split everything up into
separate DLLs, but I don't want to for a couple of reasons. And besides,
what puzzles me is why the linker seems to be sitting on its hands for a
minute or two, without seeming to do any work.
Cheers,
Steve
"Fireangel" <Fireangel@discussions.microsoft.com> wrote in message
news:4F7E2010-A924-439C-B6BB-96CABE940FC5@microsoft.com...
>
> I'm a fairly newbie to C++ and the like, so feel free to ignore...
>
> Some questions / comments:
>
> 1. Are you using alot of #Define (or anything like that. Can't remember
what they are actually called)?? I've had the displeasure of hacking
somebodies old code that had ALOT of this stuff, and to compile it took
close to 4 min. I went ahead and took out as much as I could (W/o killing
the app), and it was a noticable change.
>
> 2. You may want to consider using the option "Enable Minimal Rebuild"
under the projects configureation properties -> C/C++ -> Code Generation.
If set to YES, the compiler will only create new OBJ for those files that
have changed. It will keep the old OBJs and then link them. If you only
change 1 file between, only 1 OBJ will be recreated (instead of them all).
I think (not sure), but any files that include the file you change (Using
#include) may have to be recompiled...
>
> 3. If you're just testing / debugging, why don't you make temp dll's for
any part of the code that is "Done" or not being checked. For instance, I
have a Map.dll that containes all my stuff related to geographical maps. I
then include it as a referance, use #using, and that stuff never gets
compiled. I then create a "include all" project that has all the code files
in it. This does leave me with a lot of Test projects all over the place,
but to test it does make it fairly fast.
>
>
> Can't think of anything else. Let me know if this helps...
>
>
> GE
>
> "Steve McLellan" wrote:
>
> > Hi,
> >
> > Sorry to repost, but this is becoming aggravating, and causing me a lot
of
> > wasted time. I've got a reasonably large mixed C++ project, and after a
> > number of builds (but not a constant number) linking (and sometimes
> > compiling) becomes immensely slow, and task manager shows that link.exe
(or
> > cl.exe) is barely using any processor time, but an awful lot of RAM
(around
> > 150-200MB). I'm going to keep an eye on page faults since I can't think
of
> > anything else that could be causing this - the machine doesn't seem to
be
> > thrashing and is fairly responsive during building. Can anyone recommend
> > anything?
> >
> > Thanks,
> >
> > Steve
> >
> >
> >
- Next message: Fireangel: "RE: disabled breakpoints in a VB class"
- Previous message: William DePalo [MVP VC++]: "Re: PE Manipulation (???)"
- In reply to: Fireangel: "RE: REPOST: extremely long link times"
- Next in thread: doug mansell: "Re: REPOST: extremely long link times"
- Reply: doug mansell: "Re: REPOST: extremely long link times"
- Reply: TOM: "Re: REPOST: extremely long link times"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|