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 21:25:04 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIAEKECDAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
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: <1438-Fri25May2001192832+0300-eliz@is.elta.co.il>
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

> > 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.
> 
Well, yes, but since the test program runs realloc 10000 times,
you'd end up allocating about 10GB (and I don't have that much memory
to spare). And doing that just to get the new realloc to call
__dj_movedata seems excessive.
FWIW, I just tried again with "huge" increments - the first buffer
being grown by 1024, the second by 512 (in parallel).  This took the
old realloc a whopping 28315 ticks, while the new one took only 185
(with -O6; no profiling done).  This may include a couple of
__dj_movedata's, but is still _way_ better than the old algorithm.
Way to go Mark! :-)