Hi, On 02/16/2009 02:42 PM Frederik Holljen wrote: > I vote for making it a parameter when you create the iterator. If > someone uses this to loop through 100k objects fetching and releasing > that memory that many times is going to be a considerable amount of > work. I seem to remember that is the reason why we made it that way. > (if not, why don't you just fetch everything and use a foreach?!?)
> If you treat this as a bug and someone actually uses it to loop though > tons of objects they are justified to be pissed off. We are talking about data container objects here. These are usually very slim (logic wise) and do not contain tons of data. In addition, cases where you need to load 100k objects in one grab from the database and really process them in your request are really rare. I wrote small test scripts to test the behaviour with 100k typical persistent objects in an iterator. The results were quite interessting: php test_itr_reuse.php Time: 1.16540694237 Mem: 77776 Peak: 93812 php test_itr_new.php Time: 1.64674282074 Mem: 77624 Peak: 93260 php test_itr_clone.php Time: 1.29475498199 Mem: 78488 Peak: 94224 Interesstingly, the new creation of an object instance takes up about 41% more time. Using clone instead of a new creation only takes 11% more of time against complete re-using the object. None of the alternatives used a significant larger amount of memory (at least what PHP tells). > What do you guys mean when you say it doesn't make sense from an OO > perspective? Objects are about information and functionality encapsulation. If you receive an object from a factory (aka the iterator), you basically asume that this objects state stays stays the same, unless you call a method on it to actively make its state change. In the given case, your objects state changed silently, without you performing any action. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer t...@ez.no | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
