> 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). _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
