Re: memory profiling (was calling g_malloc & co via a vtable)
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor 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: Tue, 10 Oct 2000 04:35:24 +0200 (CEST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]