Hi Jochem,
Thank you very much for your reply!
Your reply lend me this morning to had a look again at the code, and I
have solved more than half of the trouble caused by a leak on a PhpGtk
function! :-)
Sorry for the more long reply than it should be, but I hope you'll have
the time to read it. Unfortunately, I have not fount an easyier way to
explain the thing and get to something with meaning.
Perhaps the more comprimising memory leak happened when my application
is "active", receiving and processing the data received from one or
several devices in real-time -well, it does a 300ms. delay until the
main next loop iteration starts-, and this trouble was limiting a lot
the amount of time the app. could be running before the OS have to start
swapping pages to disk, caused by the memory being leaked on each
iteration, -of course, it depends on the size or number of the
"incoming" data per minute, etc. etc.-, in wich situation I have to
finish the app. and restart it again for "clean" state, but in a nomal
case use test, it was consuming about a megabite each minute or two,
when each "round" is completed and data is received and processed from
all devices.
The improvement it is as simpler as not using styles for every node
insert as some GtkCtrees are populated when receiving and processing
data) and now it "only" takes about 300kb when before was taking one
meg. It is a only a PHP-Gtk issue as the leak is produced when copying
a widget style, a must if you want to change the style of the nodes
being inserted-updated, and not doing this helped a lot (I was doing
this about 200 times (one time per node) in minute or two wich lead to a
high amount of mem leaked...)
I really did not expect to find such a leak on a simple "$style =
$astyle->copy()" where "$astyle = gtk::rc_get_style($ctree);" !!-.
Anyway a problem persist, as 300kb per minute or two are a lot of
kilobytes if you though in that time I "only" add about 100-125 items
and update another 50 (each item have from 50 to 200 bytes of data- to a
pair of global associative arrays. And I really don't know exactly
where it is leaking, I don't know if it leaks on every iteration, or
maybe the amount of memory "used" while the application runs is what it
should, but then later when you stop the actual processing, save the
data, and want to start a new run -all variables are unset-, the memory
used stays there... and "rewriting" to the same global variables with
-probably- the same keys -but with different data- when receiving data
and processing from the devices again, does not reuse the previouly
reserved memory... it continues eating more and more. Or if you load
previously saved data from disk -it only saves the "incoming data" and
all items are re-calculated always- the same happens, more and more
memory used and nothing is reused or freed. And if I do some runs, or
load some data files, the application gets so many megs. and I need to
restart it.
I have no circular references on the arrays, and not a lot of references
at all. And removing some caused the app. to get more memory than
before, as I experienced some months ago. Only some associative arrays
being referenced with or just generated and processed from within three
objects.
I though I could ask for some help regards the garbage collector, so I
see better what is happening. I haven't got yet the time to look at the
sources and try to understand how does it work and that... :-) it could
be really a pain. And I can't update to a newer php version... as I
think it could help.
But on the other way, the actual trouble was "almost" solved some months
ago when I did some tests -very succesful I'll say regards the "not
reused" memory between application runs, so the memory used in a "run"
was used again for the new data the next time the receiving/processing
started, or when loading saved data-, but as it didn't help much in the
memory used while processing, that not helped much for the main trouble,
and felt lost 'cause though it was likely the same issue and could not
improve more the code.
I achieved that by refactoring a big piece of code and doing all the
"main" processing of global arrays from some plain functions, outside
the objects where it was/is done, but sadly that lend to some bugs -i
did it in hurry- and I had not the time to workaround them, and have to
get back to the previous version to continue developement with more
"stable" code.
Now that I have found where the most memory was being leaked when the
application is active receiving data -that was really the more
compromising thing- I'll have to find the time to refactor carefully the
main processing loop to plain functions -a 170kb. code class- and not
get caught by bugs... again :-)
Just a matter of processing a lot of global data within objects ?
Best Regards,
Gonzalo.
Jochem Maas escribió:
Gonzalo MC wrote:
Hi all,
I'm having some pain with this process. I'll try to explain it well,
my english is little bad... :-)
...
Does the php garbage collector keep track of uncollectable objects /
zvals as python gc does?
It is some way to freed some memory I know it should be really
unreferenced? Some thing like a manual force to the garbage
collection of a zval -associative array at php level-?
Perhaps should I use a different mechanism for storing the
associative arrays so I could not suffer this issue?
I don't think there is anything you can do to force garbage collection.
note that the garbage collector is not capable of freeing memory for
zvals
that contain circular references (IIRC) - e.g. 2 objects with properties
pointing to each other (I assume the same problem occurs if you have 2
arrays
with items that are references to each other [or each others items?]).
if you have circular references I would try to find a way to do it
without
them - it should help memory consumption (assuming you even have any
references in your arrays)
I take you are unset()ing the relevant variables already in your code?
If my trouble is not very clear, please don't hesitate to ask me.
Thanks in advance.
Regards,
Gonzalo.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
