Re: Helping on reducing evolution memory usage
- From: Tim Janik <timj imendio com>
- To: Federico Mena Quintero <federico ximian com>
- Cc: performance-list gnome org, GTK+ development mailing list <gtk-devel-list gnome org>, kharish novell com, Pedro Martins Waetge Kiefer <pkiefer gmail com>
- Subject: Re: Helping on reducing evolution memory usage
- Date: Fri, 16 Dec 2005 02:49:28 +0100 (CET)
On Wed, 14 Dec 2005, Federico Mena Quintero wrote:
On Wed, 2005-12-14 at 19:17 -0500, Morten Welinder wrote:
--enable-purify is the one for ORBit at least. Didn't know there was one
for glib. What exactly does --enable-gc-friendly=yes do?
It clears memory held in pools so old pointers does not confuse
memory debuggers.
The docs
(http://developer.gnome.org/doc/API/2.0/glib/glib-building.html) say
this:
--disable-gc-friendly and --enable-gc-friendly. When enabled all memory
freed by the application, but retained by GLib for performance reasons
is set to zero, thus making deployed garbage collection or memory
profiling tools detect unlinked memory correctly. This will make GLib
slightly slower and is thus disabled by default.
This could be more specific:
- When shrinking a GArray, it zeros out the memory no longer available
in the array: shrink an array from 10 bytes to 7, and the last 3 bytes
will be cleared. This includes removals of single and multiple
elements.
- When growing a GArray, it clears the new chunk of memory. Grow an
array from 7 bytes to 10 bytes, and the last 3 bytes will be cleared.
hrmm. i think zero-ing upon growing an array should either be done
always or never, but not depend on gc-friendlyness. (it's essentially
a bug if a user requests bigger arrays and uses them without intialization,
and shouldn't be covered by gc-friendlyness).
- The above applies to GPtrArray as well.
- When freeing a node from a GHashTable, it first clears the node (which
used to point to the key and the value stored at that node).
- When destroying or removing a GTree node, it clears the node (which
used to point to the value, and the left and right subnodes).
(I've just committed the text above to the documentation.)
thanks.
In Glib 2.12, this also applied to freeing a GList/GSList node, and to
creating/freeing GMemChunk blocks. It's a shame that we don't have that
in HEAD.
well, if you refer to gslice here, i'm simply not done with fine
tuning it yet. i could have waited with the final commit until i
consider everything set and done, but then it'd have missed out
the importing testing/debugging/profiling phase it's currently
going through, and it'd probably have taken forever ;)
my initial announcement:
http://mail.gnome.org/archives/gtk-devel-list/2005-December/msg00031.html
even has a list of these remaining TODOs, everyone's free
to help here, especially with profiling.
Which brings us to...
Note, the glib head has no way of disabling pools. Before the
most recen tthings, one could use --disable-mem-pools and be
happy.
Indeed. And now, the documentation for --disable-mem-pools is
incorrect, since it does nothing now.
This is all easy to fix, of course, and we need to do it before the
final 2.10.
sure, we're even taking patches from the not-so-patient people ;)
One thing I absolutely loathe, though, is to have to *recompile glib*
just to be able to run valgrind on GNOME programs. I'd really prefer to
set G_DEBUG=gc-friendly and just run my software with that.
this'd be mighty cool. i'm not sure matthias or i have the time to go
over glib and implement this though, but if someone provided a patch,
he'll get feedback and we can most probably have that for the next
major release.
To avoid calling getenv() all over the place, I'd like to have a private
g_ensure_debug() macro and possibly others to access a global
_g_enable_gc_friendly variable. This would ensure that we have called
gmessages.c:_g_debug_init(), so that the debug variables are set.
i've recently had to hack the order in which we intialize stuff.
for g_mem_gc_friendly (that's the namespace i'd put it in), you actually
want an internal initialization function that is called from gmem.c (here
a hook will have to ba added to all g_*alloc() variants) and gslice.c
(there's g_slice_init_nomessage() already) on demand.
that'll ensure it's setup before any allocations can be made.
Thoughts?
Federico
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]