Re: memory profiling (was calling g_malloc & co via a vtable)

[Darin Adler <darin eazel com>]

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.

    -- Darin