bert@helix.nih.gov (Bert Tyler) (01/29/91)
> The application we are developing has gotten to the point where the > linking operation by itself takes more than 20 minutes due to > extensive disk spooling. > ... > Will additional RAM speed up the link operation? > ... > What RAM does the linker use? (640K only, Expanded, Extended?) We had that same problem with Winfract. In our case, we were taking 15 minutes *if* we used a RAM-Disk *and* we ran the link under MS-DOS with Quarterdeck's VIDRAM package giving us access to 736K of "real" MS-DOS memory *and* we weren't using the debugging [/CO] option - otherwise it was taking a lot longer. Microsoft's LINK program apparantly uses only "real" MS-DOS memory and overflow disk files. In our case, the solution was to switch to the ILINK (Incremental link) version of the linker. Once we got around the bug in ILINK that was killing us, everything worked great. Using ILINK, we can perform a full link in under 2 minutes. The ILINK bug that we ran into involved a FAR array that was dimensioned 60K bytes - LINK was handling it correctly, but ILINK was messing it up, causing Winfract to UAE the as soon as it referenced that array. We changed our code to use a pointer and 'GlobalAlloc()', and now everything works fine.