X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Wed, 20 Feb 2002 09:08:19 -0600
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: Malloc/free DJGPP code
To: djgpp-workers AT delorie DOT com
Message-id: <3C73BBE2.9289C4F6@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en,pdf
References: <10202200445 DOT AA15769 AT clio DOT rice DOT edu> <3C734B2D DOT F82A42FB AT yahoo DOT com>
Reply-To: djgpp-workers AT delorie DOT com

CBFalconer wrote:

> I gather ALIGN = 8 is needed.  I had assumed 4 from the action of the
> present system.

No, the unsatisfactory alignment of present system is why I started this
whole thread.

To those interested in optimizing the performance of malloc, please remember
that malloc is used in a lot of different ways, and it is unwise to
concentrate on one aspect of its performance, because some other application
may suffer.  For instance, one program might be dealing with linked lists,
and doing thousands of mallocs and frees of only a few bytes each.  Another
program may be malloc'ing a few enormous arrays, freeing them in reverse
order, and expecting the freed space to be merged so that it can be used for
an even more enormous array.  (I have used a compiler with a malloc that
failed to do this.)  Still another program might be repeatedly calling the
same subroutine, which mallocs and frees its own workspace each time it is
called.  Yet another programmer might write a data input loop like this and
expect it to be fast:

   int *data=NULL;

   for (n=1; ; n++) {
      data = realloc(data, n*sizeof(*data));
      if (fscanf(infile, "%d", &data[n-1]) != 1) break;
   }

(If blocks are allocated in sizes that are powers of two, there's no reason
this last example can't be made to run fast -- though it's presently slow,
and other programmers would object to the wasted memory needed to speed it
up.)  I'm sure other djgpp workers could think of still different
situations.

By these examples, I wish to encourage people to think broadly about the
malloc optimization question.  In particular, I think we can expect some
objections if any aspect of performance is significantly worsened, even
though a new malloc performs better in some other respect.

-Eric Rudd