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
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

> 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).

- Raw text -