Re: Memory leaks

[Costin Chirvasuta <costinc gmail com>]

> Because malloc() implementations generally kept a linear linked list of
> free space, and traversed the list on a free() in case they found
> adjacent memory areas to the one you were freeing, which they could join
> together and make into a single larger area.

I'm sorry, I now understand what you mean. If what you say is true
(which I don't doubt) it's a really boneheaded mechanism in my
opinion. Defragmenting memory in realtime is a performance nightmare.
But that's irrelevant. Your point is well taken.

However, consider a modern GUI app. It's allocating and freeing
several orders of magnitude more pointers than are left at the end of
the program. So, when you finally get to the end and have searched
through all those heaps of pointers to free them and are stuck with
only 200 (say) you just give up. It's like drowning near the shore.
Plus, searching through a 200 pointer linked list should be an order
of magnitude faster than ((200/n) * (what it takes to free the n
pointers the program uses normally)). Assuming n is quite a bit larger
than 200 (which IMHO is really not far-fetched).