Evolving Web Technologies

Tomorrows Web Today

In /lib/Varien/Db/Select.php change the constructor of class Varien_Db_Select extends Zend_Db_Select
from this:

public function __construct(Zend_Db_Adapter_Abstract $adapter)
{
parent::__construct($adapter);
self::$_joinTypes[] = self::STRAIGHT_JOIN_ON;
self::$_partsInit = array(self::STRAIGHT_JOIN => false) + self::$_partsInit;
}

to this:

public function __construct(Zend_Db_Adapter_Abstract $adapter)
{
parent::__construct($adapter);
if (!in_array(self::STRAIGHT_JOIN_ON, self::$_joinTypes))
self::$_joinTypes[] = self::STRAIGHT_JOIN_ON;
self::$_partsInit = array(self::STRAIGHT_JOIN => false) + self::$_partsInit;
}

If you don’t have

if (!in_array(self::STRAIGHT_JOIN_ON, self::$_joinTypes))

then self::$_joinTypes[] keeps getting larger
like
$_joinTypes = array(
0: INNER_JOIN,
1: LEFT_JOIN,
2: RIGHT_JOIN,
3: FULL_JOIN,
4: CROSS_JOIN,
5: NATURAL_JOIN,
6: STRAIGHT_JOIN,
7: STRAIGHT_JOIN,
8: STRAIGHT_JOIN,
9: STRAIGHT_JOIN,
…
…
it just keeps adding ‘straight join’ to the array which uses a lot of memory if your importing a lot of products. The array also gets copied and parsed which uses more memory and cpu. The parsing is what I think really slows down a script.

The other memory leaks are real leaks where magento doesn’t clean up objects. It’s too complicated for me to figure those out so I compiled php 5.3 which has gc_collect_cycles() (garbage collection). Calling that cleans up the objects left in memory. But just changing the constructor made a huge difference in speed for me.