Mail Archives: djgpp-workers/2002/04/13/18:26:08
> > It's a bad couple of weeks for me (and I still haven't gotten the 2.03
> > refresh++ done) so a review will need to wait until late April at
> > earliest.
>
> I also have it mounted (no ftp) at:
>
> <http://cbfalconer.home.att.net/download/nmalloc.zip>
Yes, I still don't have my taxes done, the performance review stuff
done at work, the sessions assigned to all the people requesting
Proposals to Present at AspenWorld 2002, or use cases for the
current project, much less refresh++ done yet, so it will wait a
while more.
> with the slight addition of "evilalgo.c" which shows up other
> failings in the present library code to do with realloc. Please
> see my message in the mailing list/newsgroup which has ab
> comparisons.
>
> This shows that a major improvement is available, a factor of 2 to
> 4 in speed, and (on my machine at least) a factor of 4 in
> available memory usage.
>
> The realloc performance is, to my mind, quite serious. So I am
> once again urging people to take a good look and possibly
> incorporate it in 2.04.
These are all good things, yes. If you have time check out:
1) How does DJGPP V2.01 malloc perform (including realloc)
2) How does DJGPP v2.03 "
3) How does current CVS/v2.04 do (it's got a fixed realloc)
4) How does new nmalloc do?
With Unixy sbrk and non-move sbrk? Testing non-move sbrk() on windows
and forcing it to return address wrapped blocks?
Set unixy sbrk() and provide value of sbrk(0) at the end of each test
(shows the highest address touched). Try some tests with 1,000,000
small allocations (of like 12 bytes each).
Do the new CVS memory debug routines work with nmalloc?
Have you built GCC or EMACS with the new nmalloc to see if they work?
All of these aren't required to get it into CVS, but the more of them
we know, the more confidence we'll all have.
Without this info, anytime anything weird happens in new apps built with
CVS someone will be saying "maybe it's the new malloc" ...
- Raw text -