[comp.windows.ms] Speeding up LINK.EXE

bert@helix.nih.gov (Bert Tyler) (10/05/90)

I'm having a response-time problem with LINK.EXE when I build a large
project for Windows - the program takes forever to link if I don't
have it set up for CodeView, and twice as long if I do have it set up
for CodeView.  This is a plea to those Windows Developers who have
tricks up their sleeves that speed up this process.
 
The problem is that the program (we're porting Fractint to the Windows
environment) has tons of seperate modules, and the linker runs out
of memory and has to create a temp file.  The linker has this problem
even with the DOS verion of Fractint, but it has the problem in spades
on the Windows version.
 
So far, we are using the following tricks to give LINK as much memory
as possible:
 
1) We perform the build in the DOS environment so as to gain as much
   DOS memory as possible.
 
2) There are lots of modules that are unchanged from the DOS version,
   so we've put them into a LIB file, and built the LIB file with
   the "most likely to be referenced" modules first.
 
3) The BAT file invokes Quarterdeck's VIDRAM utility to use 96K of
   VGA memory as "DOS RAM" (so that, for instance, CHKDSK reports that
   we're using a machine with 736K of DOS memory).
 
4) We've pulled the LINK step out of the MAKE file - that is,
   MAKEFRAC.BAT looks like this:
 
   vidram on
   del linkit.flg
   nmake winfract.mak
   if not exist linkit.flg goto done
   link /NOD @winfract.lnk
   rc -K winfract.res
   :done
   vidram off
 
and WINFRACT.MAK looks (partially) like this:
 
   all: winfract.exe winfract.hlp
   
   .c.obj:
         cl /c /AM /qc /Gsw /Oas /Zpe $*.c
   ....
   
   winfract.exe: winfract.obj dialog.obj dialog2.obj select.obj \
         copy c:\autoexec.bat linkit.flg
 
 
5) We're using a RAM disk for the TEMP file.
 
6) We've tried to set up for the incremental linker (ILINK), but 
   when we use the /INC option in the LINK step, which I understand
   is the first thing you have to do to set up for ILINK, any
   attempt to run the program under Windows gives us a UAE error.
 
7) We've frantically searched the docs looking for a way to tell
   LINK to use expanded or extended memory, but there appears to
   be no way to do this.
  
Even with all of these tricks, the LINK step takes about ten minutes
on a a 16MHX PS/2 model 80 - makes me feel like I'm submitting batch
jobs on a mainframe again.  As we keep adding features, the time
keeps getting longer.  Can anyone give me more hints?
Thanks for any help you can give us.
                                         Bert Tyler
					 bert@nih.helix.gov

bullaugh@hpavla.AVO.HP.COM (Wayne Bullaughey) (10/05/90)

You might look at a program called OPTLINK from SLR Systems (412) 282-0864.
We just got it so I don't have much experience with it yet but it seems to
speed our links up by a factor of 4.  It does use expanded or extended
memory according to its manual.  We have noticed a few minor inconsistencies
between it and LINK but nothing we haven't been able to work around.