Re: Performance issue with new gtk 2.0 for win32
Peter Montgomery <[email protected]>
| Newsgroups | gmane.comp.video.gimp.windows.devel |
|---|---|
| Message-ID | <[email protected]> |
Harring,
> 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.
Just as a thought, I would look at what code is called when you press
the button to stop the timeout function. Since you are using a
stringlist (which allocates memory) and one of the columns use pixmaps
(which means more memory allocation), it seems possible that the code
that is called to free whatever resources are being allocated doesn't
get called until your timeout is stopped. In other words, I assume you
have various calls to memory freeing functions when the timeout is
stopped. I also assume that your main loop calls these functions as
well. If so, then it's likely that some sort of conditional (or
commented out code, or whatever) is preventing the memory freeing
functions from being called in the main loop.
I would also try nesting your main calls inside #ifdef / #endif pairs so
you can turn things on and off. You say that every 5 seconds a
directory is scanned that looks for an XML file, and if found, a bunch
of things happen. Okay, first, modify your loop so that when it finds
the file, it does nothing except start waiting again. If that leaks
memory, then at least you have eliminated a ton of other code as
suspect. If it doesn't leak memory, then you know your problem is
inside the #ifdef'ed code.
Now, presumably you have various high level functions that do things
like parse the XML file, scan the flat file, update the gtkList Store,
etc. If that's the case, #ifdef each of those high level calls and
repeat the process. Work through the problem at a big function level
first and isolate the general area that's causing the leak. Keep doing
this until you find the problem function. If you haven't structured
your code to use a collection of high level functions, then take the
time now to re-factor the code so it does. If everything is just jammed
into one monster function then you'll just make finding the problem even
harder.
I hope some of this helps...
Thanks,
PeterM
PS - IN your description, the gtkStringList store and the pixmaps seemed
the most logical places where some sort of allocation without free'ing
is occurring.