Re: Kill --g-mem-profile [ Was Re: Small patch to show only memory usage. ]

[Tim Janik <timj gtk org>]

On 16 Feb 2001, Owen Taylor wrote:

> 
> I'd like to get rid of all the memory profiling and debugging stuff
> in GLib:
> 
>  - It's a source of confusion and bug reports (from the way that 
>    it doesn't free memory, etc.)
> 
>  - Its far less good than possible replacements in terms of 
>    ease-of-use and power.
> 
>  - You can replace it using either LD_PRELOAD without any recompilation,
>    or using the new GLib malloc vtable stuff.
> 
> It just doesn't make sense for us to try and support and enhance such 
> a crude facility when it doesn't need to be in GLib.

i don't understand what exactly you are refering to.
we never had a --g-mem-profile, though 1.2.x offers a
--enable-mem-profile option to configure.in.
if you say we should get rid of --enable-mem-profile in
1.2.x that wouldn't be terribly bad, but i don't see a point
in removing that code for just 1.2.9 or 1.2.10, especially since
it doesn't affect normal compilation.

in HEAD we don't even have --enable-mem-profile anymore, instead we have
a vtable that virtualizes all malloc functions and a sample profiling
vtable that developers can install if they want to and they compiled
their glib without G_DISABLE_CHECKS.
since i recently implemented the sample profiling code, i'll obviously not
agree to remove that code from HEAD, it's a good sample case for use of the
malloc vtable, doesn't add enough code to count as bloat and is even quite
helpfull in figuring glib allocation behaviour (ok, maybe you don't use it,
but that doesn't mean noone does).

> 
> Regards,
>                                         Owen
> 
> 

---
ciaoTJ