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

Reply via email to