Re: [gtk-list] Re: garbbage collection in gtk
- From: Valdis Kletnieks vt edu
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: garbbage collection in gtk
- Date: Tue, 11 Jan 2000 22:31:03 -0500
On Tue, 11 Jan 2000 17:06:30 EST, Matthew D Allen <email@example.com> said:
> You don't have to worry about memory allocation as far as I know. If you
> have dynamically allocated some piece of memory somewhere without the help
> of GTK+, you should probably free that, but don't worry about the widget
> allocations because that's GTK+s business.
As far as what memory is currently malloc()'ed, this is true. One
thing you DO need to worry about is memory fragmentation - if your
application does a lot of malloc()/free() and leaves a *few* things
allocated, it's possible to end up with (for instance) 200 4K
pages, each of which only has 15 or 20 bytes in use. A good malloc()
package will try to avoid fragmentation, but it *can* be an issue to
be considered if you start adding up the memory you THINK you allocated,
but 'ps' (or whatever your system's equivalent is) says you have tons
more memory in use.
As a "worst case" example, I once had an X.500 directory that read
about 12M of data in from disk - by the time it was read in, there had
been at least 6 million(*) calls to malloc(), 120M of virtual memory in
use, but only some 45M actually still allocated. The final footprint
had a *lot* of "20 bytes allocated, 16 free, 20 allocated, 16 free"
for megabytes on end....
Operating Systems Analyst
(*) How do I know it was 6M calls? Because I diagnosed a memory overlay
problem that didn't manifest itself until after 6M calls to malloc(). ;)
What a bitch *that* was to nail without Purify or similar ;)
] [Thread Prev