Задача такая: есть большой скрипт (форум). Памяти он потребляет от 4 до 6 мб на страницу. Необходимо это число сократить до приемлемых размеров.

Есть ли какой-то способ определить, что именно занимает память, какие переменные или ресурсы? Пока не придумал ничего лучшего, чем с помощью get_defined_vars() получить список переменных и пересмотреть их, но особого результата это не дало - общий размер полученных таким образом переменных значительно меньше потребляемой памяти.

Пересматривать и анализировать весь код вручную тоже не представляется возможным - это там около 3 Мб.

Пых файл не должен весить 3мб, макс 100кб потом дробить, код по ходу дела заведомо прожорливый, тут только оптимизация, я не представляю как можно оптимизировать файл 3мб.

Ещё вариант: ООП

не знаю таких методов.
однако, могу предположить, что используется буфферизированные запросы к БД(mysql_query или подобные) с большим количеством выбираемых данных. Или несколько результатов запросов храняться одновременно. Также возможно создание графического ресурса с большим разрешением(впрочем, для форума - маловероятно). навряд ли можно оптимизировать без знания структуры, логики и кода самого кода.

Vreden, 3 мб - общий вес. Файлов там не меньше полусотни.


Скорее всего, корень зла где-то здесь. Насколько я заметил, ресурсы там освобождаются далеко не всегда.
Сейчас как раз занимаюсь настройкой XDebug, чтобы как-то отследить где именно съедаются ресурсы.

Это влияет на читабельность кода или на скорость его выполнения / потребляемые ресурсы? Имеет ли смысл, скажем, делить файл размером 120 кб на 2 по 60, при условии, что выполнятся при одном обращении будет только один из этих файлов (то есть либо include "1.php", либо "2.php")?

Прошу прощения за оффтоп. Просто интересует этот вопрос.

Wolf1994, это влияет на скорость загрузки скрипта в память и его трансляции.
Думаю, в вашем случае стоит разбить файл на два.

Alex13, спасибо за ответ.

Wolf1994, imho, для файлов <100кб, преимущественно на читабельность. Хотя при наличии Code Explorer'а читабельность сильно не страдает. В Eclips'е все классы выстраиваются в такое-же примерно дерево что для одного файла, что для кучки...

Ну и в конце концов есть "правила хорошего тона" - один класс в одном файле.  

Если файл больше 100кб  - начинают уже играть скорость трансляции и скорость чтения с диска.

единственный вариант, который я вижу - следить за объемом памяти потребляемой скриптом, т.е. скрипт должен быть в отдельном процессе

можно запускать скрипт в командной строке и вставлять бесконечный цикл, сначала посередине, потом двигать куда-нибудь и смотреть при этом на объем потребляемой процессом памяти

можно поставить Zend Core, Zend Platform и Zend Studio. При этом никакой цикл никуда двигать не нужно будет. При запуске через внутренний отладчик будет создаваться отдельный процесс php.exe, при удаленной отладке - расти будет один из процессов php-cgi.exe

По-поводу того стоит ли хранить код в одном файле или в нескольких сказать сразу нельзя. Тут есть множество нюансов.
А по сабжу верное решение нашел сам топикстартер – xdebug, все остальное ерунда.
Для профилирования запросов MySQL советую включить лог медленных запросов и лог запросов, не использующих индексы.

Кстати, если не установлено никаких оптимизаторов PHP, то может иметь смысл слить всю эту кучку файлов в один, тем самым избавившись от лишних дисковых операций.
Но это, опять же, сугубо личная ситуация каждого проекта.

хранить код надо так, чтобы его было удобно читать (Правило Экономии: Время программиста дорого; сократите его, используя машинное время., Реймонд: Искусство программирования в UNIX), экономить на количестве файлов надо в редких случаях (Пайк: Стиль программирования на C)

ну для начала я бы действительно поискал большой и медленный запрос (с помощью соответствующего лога)

youri, прочитайте последние две строчки моего предыдущего сообщения.

эти что ли? Я их читал уже  Во-первых у человека проблема не со скоростью, а с объемом потребляемой памяти, во-вторых прочитайте Пайк: Стиль программирования на C
хотя, возможно, бывают проекты, которым это может помочь, но думаю это редкость

Это сообщение отредактировал(а) youri - 12.12.2008, 14:50

Сложно разговаривать с человеком, не умеющим читать.
Если хотите конструктивного общения, потрудитесь перечитать весь топик и все посты в нем целиком.

Что касается SQL запросов - их я оптимизировал в первую очередь. Скорость выполнения так же довел до приемлемой.
А вот потребление памяти - это проблема. Пока смог выиграть только порядка мегабайта путем отключения инклудов там, где подключаемые файлы по факту не используются, но 4,5 мб - все равно много. Так что вот сижу, анализирую трейсы xdebug и ищу врагов.