🚀 go-pugleaf

For applications where memory-allocation is critical, I've quit using
malloc "raw".  The algorithm the malloc-writers chose may not be at all
suited to your application. But if it is, they might change it next
release, anyway.

I am quite happy with the slow, first fit algorithm on my Sun-3, because
it is stingy with virtual memory. Sorry to hear they are changing it,
although I can understand the rationale.

I have a small collection of memory-allocation routines that I use instead
of using malloc directly.  They get large chunks of memory from malloc,
(just as malloc typically gets large chunks from sbrk), and then they
apportion it.   They have their own free-lists, etc..

One package allows you to allocate heaps which only dispense one size of
packet. It is a pretty simple package, and using it speeds some programs
up by a factor of 100 on my Sun 3/60.  Another package is a virtual stack,
for deallocating memory in the reverse order from the order in which it
was allocated. You get a "mark", which is a virtual pointer to the top of
stack, and later release all memory above the mark.  It dispenses
arbitrary size packets. It can show extremely large speed improvements
over regular malloc.  Besides, there's the convenience of deallocating all
the packets in one go.

Of course, I also have a stacking package for fixed sized things.

Many of my utility packages, for lists, hash-tables, etc., have their own
specialized memory allocation and deallocation built into them.

I would be interested in trading with others who have similar
uncopyrighted packages.

                      Dave Jones
                      sun!megatest!djones