Оптимизация PHP-скрипта: Что быстрее function или include?

[kirosin]

человеческое зрение воспринимает 24 кадра в секунду, то есть 1 кадр длится 42 мс и все что меньше этого значения не играет никакой роли, потому отработается скрипт за 0,003 сек или за 0,0032 сек визуально неразличимо, а потому не имеет принципиальной разницы... при нынешних технологиях смысла бороться за тысячные доли секунды не вижу вообще.

[LeoN]

Сообщение от kirosin

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

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

[Виталий Желтяков]

человеческое зрение воспринимает 24 кадра в секунду, то есть 1 кадр длится 42 мс и все что меньше этого значения не играет никакой роли, потому отработается скрипт за 0,003 сек или за 0,0032 сек визуально неразличимо, а потому не имеет принципиальной разницы... при нынешних технологиях смысла бороться за тысячные доли секунды не вижу вообще.

Глупое замечание. Возможно Вы и пишите сайты с посещаемостью максимум 30 человек в день. А у меня система с 100-300 запросами в секунду - на таком уровне тысячные доли секунды играют очень большую роль.
По поводу xdebug - хороший совет, попробую на выходных протестировать.

[kirosin]

Сообщение от Виталий Желтяков

А у меня система с 100-300 запросами в секунду - на таком уровне тысячные доли секунды играют очень большую роль.

Сомневаюсь что Ваша система стоит на таком г**не, которое не справится с 100-300 запросами в секунду. Подключите один и тот же скрипт функцией и инклудом, даже если и будет разница во времени отработки, то ничтожная и 100, 300, 500 запросов в секунду это не предел даже для самой дешевой современной железки. Стремление к совершенству это канеш здорово, но в разумных пределах, и если у Вас не на синклере система стоит, то есть смысл побеспокоиться не о том чей таракан быстрее прийдет к финишу, а о личном удобстве. Мое мнение - функция ничтожно быстрее, инклуды удобнее.

[Виталий Желтяков]

Сомневаюсь что Ваша система стоит на таком г**не, которое не справится с 100-300 запросами в секунду. Подключите один и тот же скрипт функцией и инклудом, даже если и будет разница во времени отработки, то ничтожная и 100, 300, 500 запросов в секунду это не предел даже для самой дешевой современной железки. Стремление к совершенству это канеш здорово, но в разумных пределах, и если у Вас не на синклере система стоит, то есть смысл побеспокоиться не о том чей таракан быстрее прийдет к финишу, а о личном удобстве.

Вы видно не знакомы с принципом работы унитаза. Для чего по вашему у унитаза большая труба? Все г***ны могут пройти и через малую трубу. А труба большая нужна для пиковых нагрузок.

[LeoN]

Сообщение от Виталий Желтяков

Вы видно не знакомы с принципом работы унитаза. Для чего по вашему у унитаза большая труба? Все г***ны могут пройти и через малую трубу. А труба большая нужна для пиковых нагрузок.

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

[Johnatan]

Сообщение от kirosin

человеческое зрение воспринимает 24 кадра в секунду, то есть 1 кадр длится 42 мс и все что меньше этого значения не играет никакой роли, потому отработается скрипт за 0,003 сек или за 0,0032 сек визуально неразличимо, а потому не имеет принципиальной разницы... при нынешних технологиях смысла бороться за тысячные доли секунды не вижу вообще.

Одно из глупейших высказываний, которые я видел на этом форуме (к чести, остальные принадлежат модерам). Действительно, зачем что-то оптимизировать, если можно купить сервер помощнее.
Что, глючит какая-нибудь игрушка, потому что программер решил не заморачиваться с оптимизацией? Купи компьютер помощнее, вот и всё решение! А то, что твой конкурент оптимизирует свою игру и чтобы в неё играть не нужно будет обновлять компьютер - это проблемы юзверей.

По теме:
Я не зря написал ассоциацию про автомобиль. Вы сравниваете авто и эвакуатор. Типа что быстрее будет. Конечно быстрее будет объявить функцию в основном файле, чем инклюдить ещё один файл с функциями. НО! Разница будет обратной, если скорость компилирования кода (PHP компилирует код каждый раз при запуске скрипта) будет медленнее чем обращение к файлам include'ов.

Идеальный случай - использование memcached, что позволяет компилировать код один раз, а дальше он хранится в кеше уже скомпилированный и исполняется только с разными переменными. Таким образом неважно, делаете ли вы include или прописываете функции прямо в основном файле - скорость выполнения будет одинаковой (и быстрой).

[Виталий Желтяков]

Идеальный случай - использование memcached, что позволяет компилировать код один раз, а дальше он хранится в кеше уже скомпилированный и исполняется только с разными переменными.

Интересный вариант, надо попробовать.

[Виталий Желтяков]

Почитал литературу, сделал много тестов и разобрался с данным вопросом. Получилось следующее:
- На инициализацию include с одной строкой внутри расходуется ~0.0001 сек.
- На ~2000 символов (знакомест) кода расходуется ~0.0001 сек.
- На функцию расходуется времени по количеству символов, т.е. инициализация происходит мгновенно.
- На include с содержимым расходуется сумма времени инициализации и времени на интерпретацию кода (по количеству символов).
Вывод:
- Функции необходимо инициализировать сразу все, в отличии от include, который вызывается только, когда надо. Но include трудоёмкая функция. Если функций очень много и они большие по объему кода, то выгоднее использовать include. Если же объём функций мал, то быстрее будут функции.
---
Вопрос исчерпан. Спасибо всем за обсуждение. Тему можно закрывать.