Re: Performance issue with new gtk 2.0 for win32

Harring,

>  I actually trust people's code more than my own :(. So I guess I will
have to
> go to my app and track malloc, g_strdup,  and the like and do what you
are
> proposing, i.e. match with a g_free.

I'm sure it's probably too late, but this is the reason I have a
personal "generic" library that I have accumulated over the years.
Things such as malloc are wrapped in tiny functions.  The benfits to me
are two-fold:

1 - I subscribe to the school of thought that says a return value should
only return success or failure instead of returning the computed value
<plus> encoding a failure status as well.  Malloc is a prime example
since it returns NULL for error or non-NULL if it succeeds.  In
addition, you have to cast the return value (unless you need a void
pointer) which disables the compiler's ability to protect you from
yourself.

2 - By having a single place where I do all my malloc'ing, I can do
things like add reference counters or other such things to my codebase
without a struggle.  Needless to say, "free" is also in my library.  If
you use malloc directly, then you have to go into every single location
that uses it and add the code.  Of course, you could create a macro that
redirects malloc to someplace else, but then you lose the benefit I
mention in point number one.

Everyone has different coding styles.  This may not fit into yours at
all.  However, I hope it at least gives you something to think about.

>   This leads me to think that :
>   1) Win NT Task MAnager is bogus (more likely)
>   2) Gtk/GDK/GLIB libs free up memory chunks when they age ????
(Unlikely huh?)

I would look at your own code a long, long time before blaming the
Windows task manager.  It's a real central part of the UI for many
people, especially developers, and if it was bogus, then I'm sure the
community would have taken MS to task long ago.  My rule of thumb is to
PROVE that it's not my fault before I assume anything else is to blame.

    Thanks,
    PeterM