Re: Performance issue with new gtk 2.0 for win32

 Peter,

 Thanks for the advice. I did not wrap the functions because I am already using
wrappers (g_malloc/g_free)

 I am  definetely looking into my code, but I think that it is very unlikely
that I would have a memeory leak that would eat memory and free it that memory
later on -- In this cause it is not a memory leak.
    This is what I have observed - 80 MB is taken by the application, when I
stop the main/single thread, the memory goes down to 4MB -- I am sure that I am
not malloc'ing large blocks/freeing, so this is what is confusing. 

  Again, thanks for the reply and the hints.

Harring.
--- Peter Montgomery <[email protected]> wrote:
> 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
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com