Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!borland.com!sidney From: sidney@borland.com (Sidney Markowitz) Newsgroups: comp.windows.ms.programmer Subject: Re: Borland C++ : Protected Mode faster?? Message-ID: <1991May23.183740.6505@borland.com> Date: 23 May 91 18:37:40 GMT References: <1991May22.210541.1@vax1.tcd.ie> <1991May23.155105.24435@cbnewsc.att.com> Organization: Borland International Lines: 56 >From article <1991May22.210541.1@vax1.tcd.ie>, by mtynan@vax1.tcd.ie: >> >> I've heard rumours that the compile-link cycle time is greatly reduced >> when running Borland C++ in protected mode, is this true? The big bottleneck that leads to complaints about long build times is the time it takes to link a Windows app using the real mode linker under Windows in enhanced mode. Here's why and what to do about it: The real mode linker will use EMS and disk as available for swapping data (and XMS with the right switches, but it isn't really relevant to this discussion, so I'll simplify by ignoring it). Swapping to EMS is a lot faster than swapping to disk. If you run the linker under DOS it will by default use any EMS that is available. The difference in speed between swapping to EMS and to disk by the linker happens to be accentuated in a specific combination of circumstances that occurs when linking the standard libraries that are used for Windows apps. It has to do with the number of symbols and the pattern of references to them in the Windows import library and the RTL. This means that linking a Windows app using the real mode linker may be very slow if swapping is to disk, but acceptibly fast if swapping is to EMS. When running BC++ under Windows, the task will only have EMS available if you use a PIF that allocates some EMS. If you run without a PIF, the linker will not have EMS, will have to swap to disk and will likely be very slow at linking a Windows app. Even if you specify EMS in the PIF, Windows in enhanced mode has an additional gotcha: Windows simulates memory (low, EMS and XMS) by swapping to disk. So the PIF can specify EMS, the linker can think that it is swapping to EMS, but Windows can actually be swapping to disk. This extra layer of emulation makes the link even slower than having the linker swap directly to disk. To make sure that Windows uses real EMS memory, specify in the PIF that the EMS memory is locked. If you do that, Windows will not let you run the task unless the amount of EMS requested is really available. You should not have to request more than 1.5Mb for maximum performance. That will get you maximum speed from the real mode linker under Windows. However the protected mode linker, which needs to do no swapping at all, will still be faster. Typical times that I have seen on a small app were: 30 seconds using real mode linker under DOS, 40 sec under enhanced mode Windows with EMS locked, 10 minutes with EMS not locked, and 7 seconds using BCX under standard mode Windows. Another little known fact is that BCCX spawns the real mode linker, not the protected mode one. To use the protected mode linker you need to build using BCX (the protected mode IDE) or explicitly call TLINKX if you are using the command line tools. -- sidney markowitz Borland International (Languages - R&D)