Mail Archives: djgpp-workers/2002/02/20/12:31:09
> To those interested in optimizing the performance of malloc, please remember
> that malloc is used in a lot of different ways, and it is unwise to
> concentrate on one aspect of its performance, because some other application
> may suffer.
I'm painfully aware of this. I've written 3 different malloc packages in
the past - each which was optimized for a particular applications need
(and was layered in the application to fix problems with memory allocation).
One app made block requests which ranged from 4 bytes to 1/4 the available
virtual address space of the machine (about 300Mb at the time). The
*ONLY* way to make this application be able to run for months without
crashing was to use a best fit algorithm with block merging.
So, I personally don't believe there is the "ultimate" malloc which will
make everyone happy - unless it has all the algorithms in it and has
some adaptive rule engine :-)
This is one reason I hate to make major changes in a package so core,
with so much testing and years of use.
One potential fix to our current "slow free" fix would be as simple as
not merging if it takes more than some fixed number of steps to do it.
If you can't find the block in the free list in 20 steps, don't bother
merging. (If you have that many free blocks it probably doesn't matter).
It could be that merging should only be done on allocations - not on
free() - and only if there isn't a block already available in the bin.
You could argue with as cheap as memory is, we should go back to the
BSD malloc :-)
> By these examples, I wish to encourage people to think broadly about the
> malloc optimization question. In particular, I think we can expect some
> objections if any aspect of performance is significantly worsened, even
> though a new malloc performs better in some other respect.
It's a good point. Major changes to malloc() resemble religion and editor
discussions :-)
- Raw text -