Re: memory profiling (was calling g_malloc & co via a vtable)
- From: otaylor redhat com
- To: Tim Janik <timj gtk org>
- Cc: Darin Adler <darin eazel com>, Gtk Development List <gtk-devel-list gnome org>
- Subject: Re: memory profiling (was calling g_malloc & co via a vtable)
- Date: 10 Oct 2000 01:16:12 -0400
Tim Janik <timj gtk org> writes:
> On Mon, 9 Oct 2000, Darin Adler wrote:
>
> > on 10/6/00 6:55 PM, Tim Janik at timj gtk org wrote:
> >
> > > that said, i do buy into the idea of using a reliable memory profiler, the
> > > solution to let the (internal) profiler know about allocations that are
> > > meant to be static is to provide g_malloc(), g_new(), g_malloc0(), g_new0()
> > > g_renew() and g_realloc() variants for static data. those would be added to
> > > GMemVTable and be used by a profiler that installs his own memory allocation
> > > functions (could also simply be a boolean flag for the existing functions in
> > > the table).
> > >
> > > going throughout GLib/Gtk code and doing s/g_malloc()/g_static_malloc()/ where
> > > apropriate is less than 1% of the work required for 1), especially long-term
> > > and it will work much more reliable.
> > >
> > > the downside of this is, that owen was opposed to it because of increased
> > > API complexity.
> >
> > I like this idea, and I'd be willing to do some of the work. Not only would
> > this work for the internal profiler, but it would also enable me to make my
> > existing profiler (the one written by Pavel Cisler and Ramiro Estrugo and
> > checked into eazel-tools on cvs.gnome.org) work even better.
>
> well, you might have a chance convincing owen, maybe he isn't opposed as
> strongly as before...? ;)
>
> owen, could you please comment on this issue?
And what if the "static allocations" are a an object? A signal
handler on an object? A string returned g_string_free (FALSE)?
Etc.
I don't think it is feasible, or a good idea from a code
and API cleanliness point of view.
To the extent that this is worth fixing, I think it should be
done in terms of:
- compile or run time Configurable free-list handling in GLib
- moving data in GTK+ to be per-display, and an option to
close a display.
That's still not going to give you a 0-bytes alloced on exit, but
might be close enough to make people happier....
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]