[an error occurred while processing this directive]
Q: How come my program, which I ported from Borland/MS C and which
doesn't use much I/O, still runs much slower under DJGPP?
A: Explore the following possible causes for this:
-O2to produce optimized code.
If your program spends most of its time in a certain innermost loop, you
should try enabling some of the optimization options which aren't
-O2. Some of these are described in this FAQ, see
speed-related optimization options.
You can tell how much your program switches to real mode by profiling your
program. In the profile, look at the proportion of time your program
spends in low-level library functions called
calls real-mode DOS/BIOS services) and
__dj_movedata (which moves
data between the transfer buffer and your program). If this proportion is
large, try rewriting your program to minimize use of those functions which
require a mode switch, even at a price of more computation (a mode switch
usually eats up hundreds of CPU cycles).
Sometimes, some device driver that uses extended memory takes up a significant portion of it, and leaves less for DJGPP programs, which then begin to page and slow down. For example, Novell Netware's VLM redirector and client software can use up to 0.5 MB of extended memory, even if you don't log into the network. A solution is not to load such resident software, or to buy more memory.
__djgpp_exception_processoris high on the execution profile printed by
Gprof. Due to the way FP emulation is implemented in DJGPP25, it might be significantly slower than the way real-mode DOS compilers handle it. The solution is either to rewrite your code so that it doesn't use floating-point code in its inner loops, or buy an FPU.
Gprofprofiler. If you find this to be the problem, write your own, optimized versions of those functions. It's best to write them as inline assembly functions, for maximum performance. If you find library functions which are inefficient, please inform the DJGPP news group by posting to the comp.os.msdos.djgpp news group, so this could be fixed by people who maintain the library.
-pgswitch), the slow-down might be due to a bug in the DJGPP library. See slow-down in profiled programs, for more about this.