Date:	Fri, 25 May 2001 19:28:32 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	"Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
Message-Id:	<1438-Fri25May2001192832+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<CAEGKOHJKAAFPKOCLHDIIEKCCDAA.tim.van.holder@pandora.be>
Subject:	Re: ehhanced realloc test program
References:	<CAEGKOHJKAAFPKOCLHDIIEKCCDAA DOT tim DOT van DOT holder AT pandora DOT be>
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

> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Fri, 25 May 2001 17:57:03 +0200
> 
> 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.

Well, I guess if you enlarge the delta to a very large number, like
1MB, say, it will finally have to move the data, after it gets the
large chunk from sbrk.

- Raw text -