Mail Archives: djgpp/1994/08/15/01:24:16
> Compiler Time (secs)
>
> BCC 3.1, no opt 5.60
> BCC 3.1, -Os size 5.49
> BCC 3.1, -Ot time 5.44
> DJGPP 1.11m5 -O2 6.87
> DJGPP 1.12 -O2 6.43
1) Try using -O3, which adds additional optimisations. GCC
info file has a list of optimization options which you might also
consider (I think, loop-unrolling isn't included even in -O3, so
you might try it, too).
2) The runnning time is quite short (5-6 seconds), so the
overhead of loading go32 and protected mode set-up before your
program gets control can be significant in relative figures. Are
these running times characteristic of your typical application?
If so, what difference does 1 second make? If not, try running for
longer time, and see if you get better performance *ratio*.
3) You didn't mention if you use some software disk cache
like SmartDrive. Do you? If you do, you can forget about the claims
that ``DJGPP is a bit weak if you're doing lots of I/O stuff'' (but see
4 below), because the cache all but eliminates I/O performance problems.
4) On a similar machine, 7 seconds is what takes to DJGPP-compiled
program to read a 4-megabyte file (with SmartDrive installed), so if you
read multi-megabyte files like this, then yes, you might have I/O
bottleneck. I think, this is somewhat due to the fact that DJGPP
read()'s files in chunks of 4KB, which might be sub-optimal when reading
LARGE files. Otherwise, your problem is *not* I/O.
5) If your program was originally born for Borland C, then it
might have some algorithmic problems which are necessary when writing
16-bit programs. You might consider going through your code and searching
for such things, which may boost performance with GCC.
Hope this helps,
Eli Zaretskii
- Raw text -