Является ли объектно-ориентированный PHP медленным? - PullRequest
19 голосов
/ 30 октября 2009

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

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

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

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

Ответы [ 11 ]

37 голосов
/ 28 февраля 2013

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

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

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

18 голосов
/ 30 октября 2009

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

12 голосов
/ 30 октября 2009

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

2 голосов
/ 30 октября 2009

Да, каждое включение замедляет вашу программу, но это еще не все.

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

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

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

Обновлено

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

1 голос
/ 16 ноября 2012

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

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

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

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

0 голосов
/ 16 мая 2017

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

0 голосов
/ 17 января 2016

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

0 голосов
/ 13 ноября 2010

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

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

0 голосов
/ 30 октября 2009

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

0 голосов
/ 30 октября 2009

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

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

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

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