Re: Performance issue with new gtk 2.0 for win32

Harring,

    Keep looking.  I'm sure you'll find it.  It is always possible that
GTK has a leak that you have uncovered.  However, it still seems more
likely that somewhere there is a leak in your program.  I've been down
this path before where I am convinced that my code is solid and can't
possibly have a leak.  Inevitably I find the leak in some place that's
obvious only after I discover it.  For what's it's worth, I have found
three approaches that help me find bugs:

1 - Stop looking for it.  Many times I have had the exact answer to a
problem pop into my head at some random moment when I am not working on
the problem or even at my computer.  Usually it occurs when I am engaged
in some sort of activity that occupies some of my active thinking
(driving a car, for example) and lets my background thinking rise to the
top.

2 - Assume I have a problem in my code instead of assuming I can't
possibly have one.  Sometimes just starting from ground zero and going
through the problem from top to bottom again (pretending I haven't
looked at it already) can make me look at things with a fresh eye.

3 - Walk through the code while explaining it to another programmer.
This usually involves me first explaining how there can't possibly be a
bug in my code, followed by my walking them through the execution path
and pointing out how careful I have been, followed by me suddenly
realizing why my code is broken and how to fix it.

One other thing to bear in mind is the possibility that you are using a
GTK function somewhere that needs a call to another function in order to
properly release memory.  BTW, if you can talk about it, what exactly
does the program do?  Can you isolate the GUI from the worker functions?
Does your program loop and do something?  If so, can you set the code to
stop on each loop until you press a key?  If so, you can then watch the
task manager to see if memory is disappearing on each loop.

    Thanks,
    PeterM

----- Original Message -----
From: "Harring Figueiredo" <[email protected]>
To: <[email protected]>
Sent: Wednesday, December 04, 2002 8:07 PM
Subject: Re: [gimpwin-dev] 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
>
> ------------------------ Yahoo! Groups
Sponsor ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/NhFolB/TM
> ---------------------------------------------------------------------~
->
>
> To Post a message, send it to:   [email protected]
> To Unsubscribe, send a blank message to:
[email protected]
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>