X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Date: Sat, 13 Apr 2002 11:26:09 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp AT delorie DOT com
Message-Id: <4098-Sat13Apr2002112609+0300-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3CB75923.C43539D5@yahoo.com> (message from CBFalconer on Fri, 12
	Apr 2002 22:17:04 GMT)
Subject: Re: New DJGPP hogs memory (was: I need help)
References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20020410122845 DOT 00bcbbd8 AT pop DOT mail DOT yahoo DOT com>
			 <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20020410122845 DOT 00bcbbd8 AT pop DOT mail DOT yahoo DOT com> <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20020411161942 DOT 00bd1eb0 AT pop DOT mail DOT yahoo DOT com> <2593-Fri12Apr2002115014+0300-eliz AT is DOT elta DOT co DOT il> <3CB6C8FA DOT 45A31BB7 AT yahoo DOT com> <3CB71962 DOT 1D21ED00 AT yahoo DOT com> <E16w6K0-0004aW-00 AT fencepost DOT gnu DOT org> <3CB75923 DOT C43539D5 AT yahoo DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: CBFalconer <cbfalconer AT yahoo DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 12 Apr 2002 22:17:04 GMT
> 
> First, nmalloc seems to have had no faults shown up with this.  It
> appears to handle this continuous realloc about 2 to 4 times
> faster, and to use less memory in the aggregate. Note that
> evilalgo segfaulted with an input parameter of 45000, while
> nmalloc lets it handle at least 100000 without squealing (with my
> memory constraints).

The segfaults are not the important factor here, and might even hide
the actual performance issue (memory efficiency) from view: the
program crashes because it doesn't test the pointer returned by
realloc before dereferencing it.

It is much better to modify the code slightly to test whether realloc
returns NULL, and if so, print the iteration count (and/or the amount
of memory it succeeded to allocate) and exit.  Then you'd have a more
accurate quantitative measure of the memory overhead enforced by the
kind of ridiculously bad reallocation code such as the one used by
this program.