Hi Alex, > and this can not be triggered without releasing all references.
and this is what I mean. The oxid framework knows (or should) which instances have been created, so it should offer a possibility to clean up the whole chain back imho. Would be not so problematic if memory consumption would not constantly increase on the the next $oArticle = oxNew()-call. At this point memory should be released from the old stuff. Best wishes André On 17.09.2012 13:59, Alexander Kludt wrote: > Hi, > > Did you try to use unset on the object to force garbage collection? This is > all > part of the garbage collection, > and this can not be triggered without releasing all references. > > best > > > > -------------------------------------------------------------------------------- > > > > André Herrmann <mailto:[email protected]> > > 17. September 2012 13:51 > > > > > > Hi folks, > > > > several times I ran into the same issue with continuously increasing > > memory consumtion if I loop a huge list of e g. article ids like this: > > > > foreach ( $aOXIDs as $sOxid ) { > > $oArticle = oxNew('oxarticle'); > > $oArticle->load($sOxid); > > .... > > } > > > > even if I try to clone an object it will have just a tiny effect: > > > > $oBaseArticle = oxNew('oxarticle'); > > foreach ( $aOXIDs as $sOxid ) { > > $oArticle = clone $oBaseArticle; > > $oArticle->load( $sOxid ); > > .... > > } > > > > unsetting the object is useless in both cases and has no effect on > > memory consumption. > > > > I expect the problem in the factory triggering, so unsetting the last > > instance is just useless. Is there really no counterpart for oxNew() or > > load-Method for cleaning up the memory before going to next step in the > > above loop. > > > > Am I the only one who's running into that problem? And no, articlelists > > are not the solution for dealing with tenthousands of products. > > > > The only thing I currently can do is NOT to use the oxid objectframework > > in cases like this and therefore directly query the database. Not > > elegant, but it guarantees a near flat memory consumption. > > > > What about your best practices on the issue above if you need full > > variant informations? Would you agree having some kind of memory > > cleaning method inside the oxid framework? > > > > Best wishes > > > > André > > -- André Gregor-Herrmann Entwicklung, Administration, Projektmanagement mail [ [email protected] ] web [ www.fatchip.de ] FATCHIP [ GmbH ] | sitz [ Helmholtzstrasse 2-9 | 10587 Berlin ] | fon [ 030.39 88 93 51 ] | fax [ 030.39 88 93 52 ] | mail [ [email protected] ] | Ust-Id. [ DE 265567757 ] | Amtsgericht [ Berlin-Charlottenburg ] | HRB [120567 B] | Geschäftsführung [ Dipl.-Ing. Hendrik Bahr ] Be Smart, Go Green. Don’t print this email unless you really need to. _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
