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

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

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

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

Есть ли у кого-нибудь информация об этом?

Ответ 1

Здесь хорошая статья, обсуждающая эту проблему. Я также заметил несколько anecdotal настольные оценки, которые наложит OOP PHP накладные расходы на 10-15% Лично я думаю, что ООП - лучший выбор, поскольку в конце он может работать лучше, потому что он, вероятно, лучше разработан и продумано. Процедурный код имеет тенденцию быть грязным и трудноподдерживаемым. Итак, в конце - это должно быть настолько критично, что разница в производительности для вашего приложения зависит от способности поддерживать, расширять и просто понимать

Ответ 2

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

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

Нет никакого правильного ответа на который лучше для PHP

Ответ 3

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

Ответ 4

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

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

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

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

Обновление

Как и требовалось, PHP по-прежнему быстрее работает с массивом массивов, чем классы. Я смутно помню проект ORM доктрины, и кто-то сравнивал гидратацию массивов с объектами, а массивы выходили быстрее. Это не по порядку величины, но это примечательно, но это находится на французском языке, но код и результаты полностью понятны.. Просто обратите внимание, что эта доктрина использует магические методы __get и __set много, и они также медленнее, чем явный доступ к переменной, часть медлительности гидратации объекта доктрины может быть отнесена к этому, поэтому я бы рассматривал ее как худший сценарий. Наконец, даже если вы используете массивы, если вам нужно много перемещать в памяти или тонны тестов, таких как isset, или таких функций, как "in_array" (это порядок N), вы будете винить производительность выгоды. Также помните, что объекты - это просто массивы под ним, интерпретатор просто рассматривает их как специальные. Я, лично, предпочитаю лучший код, чем небольшое увеличение производительности, вы получите больше преимуществ от умных алгоритмов.

Ответ 5

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

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

Также рассмотрим мой комментарий к ответу от @Ólafur:

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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