Mail Archives: djgpp-workers/2001/05/25/15:24:34
> > 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! :-)
- Raw text -