Am 05.08.2011 19:46, schrieb Jezz Goodwin:
As Chris Stockton points out
http://news.php.net/php.internals/54391
there is always going to be additional code that has to check to see if
the reference is still valid.
But don't you see that in exchange for one little IF you get so much more...what's an NPE compared to an OOME;)
If the only concern here is running out of memory, surely you could
design a framework that could reduce it's memory usage without having to
get rid of it's objects.
It's not about a framework, it's about making use of what is available (memory & processing power) and balancing those two....and PHP is not very efficient with its objects...I might be wrong here, but I think that because PHP supports dynamic assigning of properties, it addresses them by name and not as in a c++ object by memory-offset, but I am out of my depth here, having deduced this without looking at the source-code.
For example, your ORM objects will have a store of data. You could run a
process every now and again that deletes the data from the objects
(everything except the ID of the table). And then write it in to the
framework so that if you start using the object again it goes and gets
it's data back?
Actually my use-case is single-threaded and linear, so I can't really run a second process...but if this is your solution compared to SoftReferences with one IF, then I am not sure I like yours better.
Also WeakReferences and SoftReferences are used in completely different situations. The two concepts are related but not its applications.
I just remembered something I encountered in an AS3 project I made...it's a perfect example for WeakReferences. (you might not like AS3 but you may appreciate the fact that it also uses this concept)
================
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/EventDispatcher.html#addEventListener%28%29
public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void
If you no longer need an event listener, remove it by calling removeEventListener(), or memory problems could result. Event listeners are not automatically removed from memory because the garbage collector does not remove the listener as long as the dispatching object exists (unless the useWeakReference parameter is set to true).
================