Является ли объектно-ориентированный PHP медленным?

Question

Я использовал PHP-процедурный стиль. Позже я использовал несколько классов. Позже я узнал Zend Framework и начал программировать в стиле ООП. Теперь мои программы основаны на моей собственной структуре (с элементами cms, но без какого-либо дизайна в фреймворке), который построен на верхней части Zend Framework.

Теперь он состоит из множества классов. Но чем больше я программирую, тем больше боюсь. Я боюсь, что моя программа будет медленной из-за них, я боюсь добавлять каждый другой класс, который может помочь мне развиваться, но может замедлить работу приложения.

Все, что я знаю, это то, что включение большого количества файлов замедляет приложение (с помощью eAccelerator + сбор всего кода в одном файле может ускорить приложение 20 раз!), Но я понятия не имею, что создание новых классов и объектов замедляет PHP самостоятельно ,

У кого-нибудь есть информация?

Answer 1

good article discussing the issue. Вот я и видел некоторые anecdotal bench-marks, что поставит ООП PHP накладные расходы на 10-15% Лично я думаю, что ООП является лучшим выбором, так как в конце концов, это может работать лучше, только потому, что он, вероятно, был лучше разработаны и продуманы. Процедурный код имеет тенденцию быть грязным и трудноподдерживаемым. Итак, в конце - это должно быть так важно, насколько важна разница в производительности для вашего приложения и способность поддерживать, расширять и просто понимать

Answer 2

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

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

Кроме того, наличие большого количества файлов с небольшим кодом не так уж плохо, потому что, как вы сказали, использование таких вещей, как eAccelerator или APC, представляет собой тривиальный способ получить дерьмовую тонну производительности. В то же время вы получаете, если верите в них, все прекрасные преимущества наличия и объектно-ориентированной базы кода.

Кроме того, медленный на основе запроса! = Не масштабируемый.

Обновлено

В соответствии с просьбой, PHP еще быстрее при прямой вверх манипуляции массива, чем это классы. Я смутно помню проект ORM доктрины, и кто-то сравнивал гидратацию массивов с объектами, а массивы выходили быстрее. Это не порядок, но это примечательно, но this is in french, but the code and results are completely understandable.. Просто обратите внимание, что эта доктрина использует магические методы __get и __set много, и они также медленнее, чем явный доступ к переменной, часть медлительности гидратации объекта доктрины может быть отнесена к этому, поэтому я рассматриваю ее как худший сценарий. Наконец, даже если вы используете массивы, если вам нужно много перемещать в памяти, или тонны тестов, например isset, или такие функции, как «in_array» (это порядок N), вы будете винить производительность выгоды. Также помните, что объекты - это просто массивы под ним, интерпретатор просто рассматривает их как специальные. Я, лично, предпочитаю лучший код, чем небольшое увеличение производительности, вы получите больше преимуществ от умных алгоритмов.

Answer 3

Если вы используете include_once(), вы вызываете ненужное замедление, независимо от дизайна ООП или нет.

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

Answer 4

Вы можете пересмотреть свою структуру классов и как их реализовать.Если вы сказали, что ООП медленнее, вам, возможно, придется перепроектировать свои классы и как их реализовать. Класс - это всего лишь шаблон объекта, любой плохо разработанный метод влияет на все объекты этого класса.

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

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

Answer 5

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

Answer 6

Самое главное, что нужно помнить, сначала дизайн, оптимизация. Лучший дизайн, который более удобен в обслуживании, лучше, чем код спагетти. В противном случае вы можете написать свое веб-приложение на ассемблере. После того, как вы закончите, вы можете профилировать (а не гадать) и оптимизировать то, что кажется самым медленным.

Answer 7

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

Лично я никогда не видел, чтобы сервер PHP был ограничен процессором. Проверьте свою оперативную память (вы также можете оптимизировать основные классы), и убедитесь, что вы не делаете ненужных запросов к базе данных, которые на порядок дороже, чем любая дополнительная работа процессора.

Answer 8

Если ваш проект содержит большое количество файлов и из-за характера проверки доступа к файлам в PHP и ограничений, я бы рекомендовал включить realpath_cache, ударяться параметры конфигурации в разумных количествах, и выключить open_basedir и safe_mode. Обеспечьте использование PHP-FPM или SuExec для запуска php-процесса под идентификатором пользователя, который ограничен корневым файлом документа, чтобы вернуть защитный код, обычно получаемый от open_basedir и/или safe_mode.

Вот несколько советов, почему это увеличение производительности:

• https://bugs.php.net/bug.php?id=46965
• http://nirlevy.blogspot.de/2009/01/slow-lstat-slow-php-slow-drupal.html

Также рассмотреть мой комментарий на ответ от @ Олафур:

Я нашел особенно автозагрузку, чтобы быть самым большим замедлением. PHP очень медленный для поиска каталогов и открытого доступа к файлам, чем больше функций PHP вы используете во время пользовательского автозагрузчика, тем больше замедляется. Вы можете немного помочь ему отключить безопасный режим (в любом случае он устарел) или даже open-basedir (но я бы этого не сделал), но самое большое улучшение происходит от использования автоматической загрузки и просто используйте «require_once» с полным fs чтобы потребовать все зависимости для каждого файла php, который вы используете.

Answer 9

Это меня беспокоит. См. ... процедурный код - это не всегда код спагетти, но фанаты ООП всегда предполагают, что это так.Я написал несколько процедурных веб-приложений, а также демон IRC-сервисов в PHP. Удивительно, но он превосходит большинство других, которые находятся там, и редактирование очень просто. Один из моих друзей, который обычно делает ООП, посмотрел на него и сказал, что «никакой код не имеет права быть таким чистым»

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

Существует не один прямо не ответил на что лучше для PHP

Answer 10

Если вы разрабатываете огромный объект ООП боров, который делает все, а не делать функциональную декомпозицию к различным классам, то, очевидно, будет заполнить память с бесполезным балластный код. Кроме того, с медленной каркасом вы не сможете просто приветствовать World World быстро. Я заметил, что это добрый тренд (плохая привычка), что для одного значка facebook люди включают в себя дырку, потрясающую библиотеку шрифтов, а затем появляется значок поиска с включенным шрифтоном. Каждый раз, когда они выполняют что-то необычное, они соединяют всю структуру. Если вы хотите создать приложение быстрой загрузки oop, используйте одну фреймворк только как zephir-phalcon или все, что вам нравится, и придерживайтесь его.

Answer 11

Есть способы ограничить штраф из записей include_once, и это связано с функциями, объявленными в файле 'include_once', которые сами имеют свой код в выражении 'include'. Это загрузит вашу библиотеку кода, но только те используемые функции будут загружать код по мере необходимости. Вы берете второй файловый системный хит для включенного кода, но использование памяти практически не имеет значения для самой библиотеки, и загружается только код, используемый вашей программой. Удаленный доступ из второго доступа к файловой системе может быть уменьшен путем кэширования. При работе с большим проектом PHP на основе процедур, это обеспечивает низкое использование памяти и быструю обработку. Не делайте этого с помощью классов. Это будет для производственного экземпляра, сервер разработки покажет все штрафы за хиты, так как вы не хотите, чтобы кеширование было включено.