3
Функция db_fetch_row выглядит как
function db_fetch_row($q) //row fetching
{
$res = mysql_fetch_row($q["resource"]);
if ( $res )
{
foreach( $q["columns"] as $column_name => $column_index )
$res[$column_name] = $res[$column_index];
}
return $res;
}
, хотя делает то же самое, что и
function db_fetch_row($q) //row fetching
{
return mysql_fetch_array($q["resource"]);
}
Причем дело не в старинности ShopCMS, т.к. mysql_fetch_array() есть аж с PHP3.
Если результат запроса содержит несколько сотен строк, то на слабом сервере, как мне кажется, разница будет заметна.
Соответственно, становится не нужным и создание подмассива ["columns"] (больше он нигде не используется) в функции db_query, оно ведь тоже отнимает время при объемном результате запроса.
$res["columns"]=array();
$column_index = 0;
while($xwer = @mysql_fetch_field($res["resource"])){
$res["columns"][$xwer->name] = $column_index;
$column_index++;
}
По хорошему, все $res["resource"] и $res['resource'] надо заменить на просто $res, $q["resource"] на $q, а $Result["resource"] на $Result, т.к. обращение к элементу массива всегда дольше, чем к простой переменной. Но это уже, наверное, копейки.
Никто не пробовал такие замены в качестве оптимизации скорости работы? Я заменил, все работает, но на моих двустах тестовых товарах разницу не заметишь даже в цифрах, т.к. она будет невелика на фоне других случайно влияющих факторов.
PS. Это я еще до рекурсивной функции создания массива категорий не добрался. Там же вообще трындец при большом количестве категорий. Уверенно предполагаю, что вместо рекурсивного обхода "по одному запросу на категорию" (а может и больше) то же самое можно решить одним общим запросом, а результат затем обработать уже на PHP, что будет (возможно) быстрее. Или вообще оба массива категорий в кэше каком-либо хранить, пересоздавая только по созданию/удалению/перемещению категории в админке.
