Re: Memory leaks
- From: Liam R E Quin <liam holoweb net>
- To: Costin Chirvasuta <costinc gmail com>
- Cc: gtk-app-devel-list <gtk-app-devel-list gnome org>
- Subject: Re: Memory leaks
- Date: Thu, 10 Feb 2011 02:13:05 -0500
On Thu, 2011-02-10 at 00:43 +0200, Costin Chirvasuta wrote:
but aside from that it's a pure waste of CPU cycles.
I hate to throw fuel in the fire but this is just absurd!
How complex is freeing 200 pointers? O(1)?
Years ago my text retrieval package had an option to call free() for all
the data structures on exit, basically just for debugging. It made the
programs often go really slow when they exited - adding tens of seconds
wasn't uncommon.
Why?
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.
If your application had a larger heap than fit comfortably into main
memory, every free() would bring in every page from disk in turn and
swap out the earlier ones... and with the next free() the process would
repeat... and then just a few million calls to free() could take many
many minutes.
But on exit() without doing a free, it's indeed O(1) because the OS just
marks the pages as unused, without caring about the no-longer-relevant
internal structure.
These days things are much faster, but a very simple test program
indicated that free() can be comparable in some cases in time overhead
to malloc(). I'll attach the program; you can vary the constant N and
also the amount allocated each time. Using a random amount would be a
fairer simulation, and would also might make some implementations of
malloc/free() run quite a bit slower.
Whether it's better to add something to an API or to write a valgrind
special-case file is another matter... consider code that creates a
singleton factory,t hat would now have to add that factory to a linked
list of items to destroy, together with (possibly new) code to destroy
it... using a bit more memory, a bit more code space, more lines of code
to maintain, slightly bigger API, documentation, translations...
So, I agree it's a good idea to do (and as I mentioned, I've done it
myself in the past) but it's for sure not a case of adding one simple
line of O(1) code...
Best,
Liam
--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]