Hi André The last time I've tried to work with "by reference call" on a already initiated oxarticle object. But it still needs too much memory to run..
Mit freundlichen Grüßen Tim Aniol Softwareentwickler ************************************* shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Tel (09 11) 2 55 66 - 10 Fax (09 11) 2 55 66 - 29 eMail [email protected] Web www.shoptimax.de ************************************* Geschäftsführung: Friedrich Schreieck Ust.-IdNr.: DE 814340642 Amtsgericht Nürnberg HRB 21703 -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von André Herrmann Gesendet: Montag, 17. September 2012 14:10 An: [email protected] Betreff: Re: [oxid-dev-general] Base unload method for avoiding constantly increasing memory consumption? What do you think about this? 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 _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
