saen
да уверен, сборщик не работает, как нужно смотрю, как встроенными функциями, так и отладчиком.
специально, переписывал тяжелые функции что бы без свойств (хранилища в объекте) работать.
структура
Код:
Engine (корень он же реестр, нет хранилища, только текущая конфигурация)
Engine->cache (воздействие с file, string, хранилище свое)
Engine->control (воздействие metadata)
Engine->curl
Engine->date (воздействие с string)
Engine->db
Engine->debug
Engine->document (воздействие с string, metadata и внутренними классами, хранилище свое)
Engine->document->Title
Engine->document->key
Engine->document->desc
Engine->element
Engine->encryption
Engine->file
Engine->gzip
Engine->hall (воздействие с user, хранилище свое)
Engine->language (воздействие с file, хранилище свое)
Engine->metadata (воздействие с file, cache, хранилище свое)
Engine->module (воздействие с file, хранилище свое)
Engine->string
Engine->template (воздействие с file, string, cache, хранилище свое)
Engine->user
Engine->variable (воздействие с file, metadata)
центрального хранилища нет, у каждого класса оно свое.
у меня проблема в том что на малых объемах данных, невидно расхода оперативной памяти, те когда идет выборка 10-500 записей,
но при больше видно.
в некоторых классах есть углубления, до 3-4 уровня, но это специфические модули.
наглядный пример утечки
было
PHP:
function result($type=MYSQL_ASSOC) {
global $engine, $mem;
if ($this->cached && $this->load):
$rec = null;
@list(, $rec) = @each($this->cache);
return $rec;
else:
return mysqli_fetch_array($this->id, $type);
endif;
}
тут память постоянно росла
стало
PHP:
function result($type=MYSQL_ASSOC) {
global $engine, $mem;
if ($this->cached && $this->load):
return array_shift($this->cache);
else:
return mysqli_fetch_array($this->id, $type);
endif;
}
тут уменьшается, а подобные алгоритмы используются во многих CMS