From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Now Slower?
Date: 27 Feb 2001 14:50:00 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 39
Message-ID: <97geqo$da1$1@nets3.rz.RWTH-Aachen.DE>
References: <3A97302F DOT 7561 AT earthlink DOT net> <3405-Sat24Feb2001100029+0200-eliz AT is DOT elta DOT co DOT il> <3A97BB6A DOT 2E4C AT earthlink DOT net>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 983285400 13633 137.226.32.75 (27 Feb 2001 14:50:00 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 27 Feb 2001 14:50:00 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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.