Я использовал PHP-процедурный стиль. Позже я использовал несколько классов. Позже я узнал Zend Framework и начал программировать в стиле ООП. Теперь мои программы основаны на моей собственной структуре (с элементами cms, но без какой-либо конструкции в рамках), которая построена на вершине Zend Framework.
Теперь он состоит из множества классов. Но чем больше я программирую, тем больше боюсь. Я боюсь, что моя программа будет медленной из-за них, я боюсь добавлять каждый другой класс, который может помочь мне развиваться, но может замедлить работу приложения.
Все, что я знаю, это то, что в том числе много файлов замедляет приложение (с помощью eAccelerator + сбор всего кода в одном файле может ускорить приложение в 20 раз!), Но я понятия не имею, что создание новых классов и объектов замедляет PHP самостоятельно.
Кто-нибудь есть информация об этом?
Вот хорошая статья, обсуждающая эту проблему. Я также видел некоторые анекдотические оценки , которые наложили OOP PHP накладные расходы на 10-15%. Лично я считаю, что ООП – лучший выбор, поскольку в конце он может работать лучше только потому, что он, вероятно, был лучше разработан и продумано. Процедурный код имеет тенденцию быть грязным и трудноподдерживаемым. Таким образом, в конце – это должно быть так важно, как разница в производительности для вашего приложения и способность поддерживать, расширять и просто понимать
Это меня беспокоит. См. … процедурный код – это не всегда код спагетти, но фанаты ООП всегда предполагают, что это так. Я написал несколько процедурных веб-приложений, а также демон IRC-сервисов в PHP. Удивительно, но он превосходит большинство других, которые находятся там, и редактирование очень просто. Один из моих друзей, который обычно делает ООП, посмотрел на него и сказал: «никакой код не имеет права быть чистым»
Хороший программист может написать отличный процедурный код без привлечения накладных классов. Плохой программист всегда будет писать дрянной код ООП, который замедляет работу.
Нет ни одного правильного ответа на который лучше для PHP
Самое важное, что нужно помнить, – сначала дизайн, оптимизация. Лучшая конструкция, которая более удобна в обслуживании, лучше, чем код спагетти. В противном случае вы можете написать свое веб-приложение на ассемблере. После того, как вы закончите, вы можете профилировать (а не гадать) и оптимизировать то, что кажется самым медленным.
Да, каждый из них делает вашу программу медленнее, но есть нечто большее, чем это.
Если вы разложите свою программу, во многих файлах, есть точка, в которой вы включаете / разбираете / выполняете наименьший объем кода, а также накладные расходы на включение всех этих файлов.
Кроме того, наличие большого количества файлов с небольшим количеством кода не так уж плохо, потому что, как вы сказали, использование таких вещей, как eAccelerator или APC, является тривиальным способом получить верный тон производительности. В то же время вы получаете, если верите в них, все прекрасные преимущества наличия и объектно-ориентированной базы кода.
Кроме того, медленный на основе запроса! = Не масштабируемый.
обновленный
Как и требовалось, PHP по-прежнему быстрее работает с массивом массивов, чем классы. Я смутно помню проект ORM доктрины, и кто-то сравнивал гидратацию массивов с объектами, а массивы выходили быстрее. Это не порядок, но это примечательно, но это на французском, но код и результаты вполне понятны. , Просто обратите внимание, что эта доктрина использует магические методы __get и __set много, и они также медленнее, чем явный доступ к переменной, часть медлительности гидратации объекта доктрины может быть отнесена к этому, поэтому я рассматриваю ее как худший сценарий. Наконец, даже если вы используете массивы, если вам нужно много перемещать в памяти, или тонны тестов, например isset, или такие функции, как «in_array» (это порядок N), вы будете винить производительность выгоды. Также помните, что объекты – это просто массивы под ним, интерпретатор просто рассматривает их как специальные. Я, лично, предпочитаю лучший код, чем небольшое увеличение производительности, вы получите больше преимуществ от умных алгоритмов.
Если ваш проект содержит много файлов и из-за характера проверки доступа к файлам PHP и ограничений, я бы рекомендовал включить realpath_cache , увеличить настройки конфигурации до разумных чисел и отключить open_basedir и safe_mode . Обеспечьте использование PHP-FPM или SuExec для запуска php-процесса под идентификатором пользователя, который ограничен корневым элементом документа для восстановления безопасности, обычно получаемой от open_basedir и / или safe_mode .
Вот несколько указателей, почему это увеличение производительности:
Также рассмотрите мой комментарий к ответу от @ Ólafur:
Я нашел особенно автозагрузку, чтобы быть самым большим замедлением. PHP очень медленный для поиска каталогов и открытого доступа к файлам, чем больше функций PHP вы используете во время пользовательского автозагрузчика, тем больше замедляется. Вы можете немного помочь ему отключить безопасный режим (в любом случае он устарел) или даже open-basedir (но я бы этого не сделал), но самое большое улучшение происходит от использования автоматической загрузки и просто используйте «require_once» с полным fs чтобы потребовать все зависимости для каждого файла php, который вы используете.
Если вы используете include_once (), вы вызываете ненужное замедление, независимо от дизайна ООП или нет.
ООП добавит накладные расходы на ваш код, но я буду держать пари, что вы его никогда не заметите.
Использование больших фреймворков для веб-приложений, которые на самом деле не требуют столь большого количества классов для всего, вероятно, является самой плохой проблемой, о которой многие не знают. Разделите его, по крайней мере, чтобы не включать в себя каждый бит кода, сохраняйте только то, что вам нужно, и бросайте все остальное.
Вы можете пересмотреть свою структуру классов и как их реализовать. Если вы сказали, что ООП медленнее, вам, возможно, придется перепроектировать свои классы и как их реализовать. Класс – это всего лишь шаблон объекта, любой плохо разработанный метод влияет на все объекты этого класса.
Используйте наследование и полиморфизм, насколько это возможно, это позволит эффективно уменьшить количество поведения и независимые методы, необходимые вашим классам, но прежде всего вам нужно создать хорошую карту наследования, абстрагируя свой первый или материнский классы столько, сколько сможете.
Не проблема в том, сколько классов у вас есть, проблема в том, сколько методов, свойств или полей у них есть и насколько хорошо эти методы структурированы. Наследование уменьшает количество методов для драматического проектирования и объем кода, который должен быть скомпилирован.
Как отметили некоторые другие люди, на OO PHP есть легкие накладные расходы, но вы можете компенсировать это, сосредоточив усилия по оптимизации на основных классах, из которых происходят ваши другие другие классы. Именно поэтому C ++ становится все более популярным в мире высокопроизводительных вычислений, традиционно являющихся сферой C и Fortran.
Лично я никогда не видел, чтобы сервер PHP был ограничен процессором. Проверьте свою оперативную память (вы также можете оптимизировать основные классы), и убедитесь, что вы не делаете ненужных запросов к базе данных, которые на порядок дороже, чем любая дополнительная работа процессора.
Если вы создаете гигантский объект ООП, который делает все, а не выполняет функциональную декомпозицию для различных классов, вы, очевидно, заполняете память бесполезным балластным кодом. Кроме того, с медленной каркасом вы не сможете просто приветствовать World World быстро. Я заметил, что это добрый тренд (плохая привычка), что для одного значка facebook люди включают в себя дырку, потрясающую библиотеку шрифтов, а затем появляется значок поиска с включенным шрифтоном. Каждый раз, когда они выполняют что-то необычное, они соединяют всю структуру. Если вы хотите создать приложение быстрой загрузки oop, используйте одну фреймворк только как zephir-phalcon или все, что вам нравится, и придерживайтесь его.
Есть способы ограничить штраф из записей include_once, и это связано с функциями, объявленными в файле «include_once», которые сами имеют свой код в выражении «include». Это загрузит вашу библиотеку кода, но только те используемые функции будут загружать код по мере необходимости. Вы берете второй файловый системный хит для включенного кода, но использование памяти практически не имеет значения для самой библиотеки, и загружается только код, используемый вашей программой. Удаленный доступ из второго доступа к файловой системе может быть уменьшен путем кэширования. При работе с большим проектом PHP на основе процедур, это обеспечивает низкое использование памяти и быструю обработку. Не делайте этого с помощью классов. Это будет для производственного экземпляра, сервер разработки покажет все штрафы за хиты, так как вы не хотите, чтобы кеширование было включено.