Hi André,
I don't know if this helps in your case but as far as we investigated this:
when loading article lists OXID by default also loads the parent product
and all of the variants of the parent product (although you just wanted
to load the given variant). This eats up memory.
Fortunately there is the setting settings/performance/load variants in
article lists in the backend.
Did you try to deactivate this option?
Cheers,
Daniel Schlichtholz
Am 17.09.2012 14:19, schrieb André Herrmann:
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 <[email protected]>
An: <[email protected]>
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 [ [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
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
