Re: Performance issue with new gtk 2.0 for win32

Harring Figueiredo <[email protected]>
Newsgroups gmane.comp.video.gimp.windows.devel
Message-ID <[email protected]>
--- Peter Montgomery <[email protected]> wrote:
> 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.

  This is funny -- That was exactly what I was thinking -- just like when we
are banging our heads with Math homework --once we go away for a second, we
find the solution.
> 
> 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.

  I really think my code is <b>NOT</b> one of the best :)
> 
> 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.  

  I dound one -- g_strsplit -- apparentley we have to call g_free_v (or the
like)

>BTW, if you can talk about it, what exactly
> does the program do?  

  The programm is really silly. 
 1) It scans a directory every, say, 5 seconds, looking for some XML file. 
 2)When it finds files, it parses the file, populate a gtk_list_store, and add
to anothe flat file to communicate with a proprietary software.
  3) then it scans this flat file, and check for some byte that indicates the
status of that "order", and updates the status field on the gtkListStore
everytime it gets a new one. (The GtkListSTore has a column that that is of
type GDK_PIXMAP and several others that are of type G_STRING.

 Here is the ordeal:

 To start scanning, I have a button on a toolbar that sets up the time out
function. While it is scanning, the memory keeps growing and growing, but when
I stop the timeot fuction, the memory decreases.



>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.

   I woudl have to add a few lines to be able to do this. I might go on this
path later.
> 
>     Thanks,
>     PeterM
> 


  Thanks again !!!

Harring.

> ----- 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/
> >
> >
> >
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.