Hi,
I can remember that I tried it like this some time ago and it did not
work for me as expected, which lead me to the code I posted first.
I will try this again with only building one instance of the object and
just using the load method again and again.
Regards
André
On 17.09.2012 14:12, Bernd Hasis wrote:
> Hi,
>
> my solution and I dont have any "bad" results by doing it this way:
>
> $oArticle = oxNew('oxarticle');
>
> foreach ( $aOXIDs as $sOxid ) {
>
> $oArticle->load( $sOxid );
> }
>
> So, I init the object before the foreach and use the same object on every
> foreach iteration.
>
> Mit den besten Grüßen aus Lünen
> i. A. Bernd Hasis
>
>
>
> -----Ursprüngliche Daten-----
> Datum: 17.09.2012 13:51:47
> Von: André Herrmann <andre.herrm...@fatchip.de>
> An: <dev-general@lists.oxidforge.org>
> Betreff: [oxid-dev-general] Base unload method for avoiding
> constantlyincreasing memory consumption? What do you think about this?
> Vorgang: T-CC8GZDZCJA-72
>
>> 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 [ andre.herrm...@fatchip.de ]
>>
>> 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 [
>> kont...@fatchip.de ] | 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
>> dev-general@lists.oxidforge.org
>> http://dir.gmane.org/gmane.comp.php.oxid.general
>
> _______________________________________________
> dev-general mailing list
> dev-general@lists.oxidforge.org
> http://dir.gmane.org/gmane.comp.php.oxid.general
--
André Gregor-Herrmann
Entwicklung, Administration, Projektmanagement
mail [ andre.herrm...@fatchip.de ]
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 [ kont...@fatchip.de ]
| 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
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
