From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: Re: ehhanced realloc test program
Date: Fri, 25 May 2001 17:57:03 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIIEKCCDAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3B0D2240.25662.FBD929@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> What I have isn't in final form yet but it works.
> 
> [snip]
I added this to a copy of CVS malloc.c (renaming realloc
to new_realloc) and linked this file with an adjusted
version of your previous test program (with both reallocs
tested after eachother).

Even with a high increment count (256), not a single tick
passed during the entire loop (while the old realloc's loop
took 5610 ticks).

Pretty darn impressive. (this sentence's previous incarnation
was presumably blocked by DJ's profanity filter :-) )

According to gprof, the speed culprit is __dj_movedata(),
which makes sense, since the old realloc was essentially
copying everything over.

By having the test realloc two seperate pointers in parallel,
I was able to get new_realloc to register on the clock (but
no more than 5 ticks, apparently caused by calls to __brk).