[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Helping on reducing evolution memory usage
From:       Matthias Clasen <matthias.clasen () gmail ! com>
Date:       2005-12-15 4:41:58
Message-ID: cbccc63c0512142041x5b4f2840i3bda31c5fcb8395e () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

[Attachment #4 (text/plain)]

On 12/14/05, Federico Mena Quintero <federico@ximian.com> wrote:
>
>
> > 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.
>
> 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.
>
> 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.
>
> Thoughts?


You want to check out  g_slice_set_config(), which allows you to turn off
various
aspects of the slice allocator. I believe timj also has plans for making
this runtime-configurable
with an env var.

Matthias

[Attachment #5 (text/html)]

On 12/14/05, <b class="gmail_sendername">Federico Mena Quintero</b> &lt;<a \
href="mailto:federico@ximian.com">federico@ximian.com</a>&gt; wrote:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br>&gt; \
Note, the glib head has no way of disabling pools.&nbsp;&nbsp;Before the<br>&gt; most \
recen tthings, one could use --disable-mem-pools and be<br>&gt; \
happy.<br><br>Indeed.&nbsp;&nbsp;And now, the documentation for --disable-mem-pools \
is <br>incorrect, since it does nothing now.<br><br>This is all easy to fix, of \
course, and we need to do it before the<br>final 2.10.<br><br>One thing I absolutely \
loathe, though, is to have to *recompile glib*<br>just to be able to run valgrind on \
GNOME programs.&nbsp;&nbsp;I'd really prefer to <br>set G_DEBUG=gc-friendly and just \
run my software with that.<br><br>To avoid calling getenv() all over the place, I'd \
like to have a private<br>g_ensure_debug() macro and possibly others to access a \
global<br>_g_enable_gc_friendly variable.&nbsp;&nbsp;This would ensure that we have \
called <br>gmessages.c:_g_debug_init(), so that the debug variables are \
set.<br><br>Thoughts?</blockquote><div><br>You want to check out&nbsp; \
g_slice_set_config(), which allows you to turn off various <br>aspects of the slice \
allocator. I believe timj also has plans for making this runtime-configurable  \
<br>with an env var.<br><br>Matthias<br></div><br></div><br>



_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


[prev in list] [next in list] [prev in thread] [next in thread]