mtynan@vax1.tcd.ie (05/23/91)
I've heard rumours that the compile-link cycle time is greatly reduced when running Borland C++ in protected mode, is this true? At the moment, running in real mode, it takes about 12 minutes to compile and link and link an 80 line windows .exe on my 16Mhz 286 machine. Would the speed benifits of running in protected mode justify buying the extra 1MB of RAM I need? I'd be grateful for any info anyone can offer!
oneel@heawk1.gsfc.nasa.gov ( Bruce Oneel ) (05/23/91)
In article <1991May22.210541.1@vax1.tcd.ie> mtynan@vax1.tcd.ie writes:
I've heard rumours that the compile-link cycle time is greatly reduced
when running Borland C++ in protected mode, is this true?
At the moment, running in real mode, it takes about 12 minutes to compile
and link and link an 80 line windows .exe on my 16Mhz 286 machine.
Would the speed benifits of running in protected mode justify buying the
extra 1MB of RAM I need?
I'd be grateful for any info anyone can offer!
In a word, YES. I've got about 300 lines of my own code plus my .h
file, plus windows.h, (so what, about 4000 lines of code) and I can
build the program in about 1 minute. I use bcx, a 12mhz 286, and 2.5
meg of memory and a slow (65ms) hard disk.. When it compiles/links it
seems to leave about 1 meg free, so you could get away with a little
less memory. In my opinion, the best purchase I ever made was $100
for 2 meg of memory.
Just for comparision, when I first got bc++ I was using a 8mhz 8086
and it took over an hour for the compile to fail for lack of memory on
the todo example in \borlandc\examples. It took maybe a minute or a
minute and a half for the newer system to compile and link it
sucessfully.
for what it's worth.
bruce
--
Bruce O'Neel oneel@heasfs.gsfc.nasa.gov
NASA/GSFC/STX/Code 664ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (05/23/91)
They aren't rumors - read the manual. Protected mode is much faster and well worth the expense of extra memory. Only disadvantage I know of is that it must be run from std. mode. Terrell
aaron@backyard.bae.bellcore.com (Aaron Akman) (05/23/91)
In article <1991May23.133853.24303@mnemosyne.cs.du.edu>, ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes: > > They aren't rumors - read the manual. Protected mode is much faster and > well worth the expense of extra memory. Only disadvantage I know of is > that it must be run from std. mode. My compiles are running well. I use tkernel hi=yes kilos=1024 and then I use BCCX from inside of MAKE. My problem is I can't seem to run it from within a Window---I have to exit windows compile, then go back in. It always runs out of memory...I believe it's while RC is running, but it might be during the link step. Any magic Windows settings out there? I tried playing with a PIF for a DOS window to run MAKE in, but no luck. ___________________________ Aaron Akman aaron@backyard.bellcore.com 908-699-8019
markb@csg.uwaterloo.ca (Mark Brezina) (05/23/91)
I'm running Borland C++ on a 2 megabyte 386 machine in protected mode. It takes about 15 seconds to compile and link a 300 line program. I'm not sure if you'd get the same results on a 286, (it may take 30 seconds) I think it would be worth the money to buy an extra megabyte of RAM.
tjr@cbnewsc.att.com (thomas.j.roberts) (05/23/91)
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? > > At the moment, running in real mode, it takes about 12 minutes to compile > and link and link an 80 line windows .exe on my 16Mhz 286 machine. > > Would the speed benifits of running in protected mode justify buying the > extra 1MB of RAM I need? > > I'd be grateful for any info anyone can offer! I noticed that the biggest reduction in compile-time was due to using precompiled headers - now error messages come out in 3-5 seconds on my initial Windows program (~140 lines of C++). I have an AT&T 6386/SX (16 MHz 386SX) with 2.0 Mb, and use bcx under windows in standard mode. The entire compile/link/resource-compile sequence (ultimately successful) takes ~ 30 sec. My only problem is memory - with 2MB, I cannot reserve 640kb for tkernel, run windows, run bcx, run the resource toolkit, AND run my test program. The big memory hog is the resource toolkit (and windows, of course, and tkernel). Tom Roberts att!ihlpl!tjrob TJROB@IHLPL.ATT.COM
sidney@borland.com (Sidney Markowitz) (05/24/91)
>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 <sidney@borland.com> Borland International (Languages - R&D)