Mail Archives: djgpp/2001/02/27/09:55:04
Joe Wright <joewwright AT earthlink DOT net> wrote:
> Eli Zaretskii wrote:
>> How much larger and how much slower? It is important to know the
>> approximate figures to tell you if what you see is expected or some
>> kind of installation/usage snafu.
[... lots of unused quoted text snipped...]
> I haven't tested and measured everything rigorously yet. I have a
> program that implements several kinds of sorts. Under 2.7.2.1 I
> produce a 49,152 byte .exe and with 2.952 67,584 bytes.
As Eli hinted, that's a relatively small amount of change. Your app's
own code is still much smaller than that added by the runtime
environment and libc functions. I.e. it's a library difference,
mainly. To make a valid code size comparison, you should compile your
source to an .o file, but not link, and check the 'size' output, for
both compilers:
gcc -c foo.c
size foo.o
> I run the sort program in a DOS window on Win95. The sort fills the
> screen with the array to be sorted.
That's a rather bad idea, if you want to test compiler speed. I/O
operations can behave in all kinds of weird ways, and they're mainly
determined by library and system overhead, not by the raw power of the
compiler compiling your source code.
For meaningful compiler speed testing, you have to reduce the timed
part of the benchmark program to the bare bones: nothing but the
actual tested code, and a few added lines to measure the time. Only do
any I/O *after* the tested code has completed. Or, maybe even better:
no I/O at all, and time it from the outside, e.g. using 'redir -t' or
the 'time' builtin command of 'bash'.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -