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

[Tim Janik <timj gtk org>]

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?

> 
>     -- Darin
> 

---
ciaoTJ