Comments 116
Вообще смущает 30 запросов в секунду на M2. Если это с включенным FPC то по сути автор тестировал memcached/redis/filesystem. Или FPC был выключен?
Не менее важно чтобы там был продакшн-режим и разогретый кэш.
В интернет-магазинах показатель для бенчмарка — количество заказов в минуту: это самая важная и тормознутая часть, обычно, а не RPS.
На сайте симфони опубликовали ссылку где в тестировании в 2 раза получилась разница в производительности www.phpbenchmarks.com/en
Как думаете почему у вас другие результаты?
Поэтому можно было включить какую-то опцию или отключить — важнее было узнать, как скрипт работает на конкретном PHP.
Кроме того, Symfony 4.0 is almost three times as fast as Laravel 5.5.
twitter.com/dunglas/status/940512934714904577
Я не такой уж и профи, чтобы свободно об этом говорить, но революционным показался именно 5.3, когда появились неймспейсы (хотя я тогда мало работал с большими скриптами и не до конца мог понять преимущества), а также анонимные функции, а в PHP 5.4 хорошо запомнился синтаксический сахар объявления массивов с помощью [].
Ну по сути 5.3 стал промышленным стандартом, до сих пор, наверное, можно было бы найти несколько хостингов с этой патченой версией.
Каждая версия добавляла немного в производительности, но только в 7.0 случился столь сильный рывок из-за плотного переписывания внутренностей.
Ну а второе важное явление в языке — это развитие экосистемы, которая помогала избегать велосипедостроения. Composer ну очень сильно упростил жизнь в поддержке модулей и фреймворков в более-менее актуальном состоянии.
Отделить собственно мое развитие от параллельного развития языка довольно сложно, но, думаю, если что — меня дополнят.
А если код совсем ООП не использует (и неймспейсы тоже), то есть сплошная лапша — будет ли выгода от переезда на семёрку, или ничего не изменится?
Просто вспоминается история из реальной практики, когда некий несложный код работал на 5.2, внезапно, чуть быстрее чем на 5.4, хотя, казалось бы…
переработали в целом то как происходит работа с памятью (влияние на кэш процессора, размеры структур, оптимизация массивов и объектов (а от объектов совсем вы не уйдете)). Не забывайте — wordpress не особо "ооп" использует, по большому счету это та самая лапша.
состоящий из аккуратных функций — обязательно лапша
все соль в управлении стэйтом и зависимостями.
если не юзать ООП
шутки ради — когда люди юзают классы — это еще не ООП)
А вот как по скорости будет? Так же, хуже, лучше?
вам универсальный ответ?
В целом, инстанцирование объекта весьма дешевая операция, и ситуации когда в рамках стандартного проекта на PHP вам надо инстанцировать внушительный граф объектов все же является крайне редкой.
То что в условиях простой виртуальной машины как в PHP динамическая диспетчеризация накладывает определенные накладные ресурсы — это тоже факт, то эту проблему может решить JIT.
Ну и опять же, в случае PHP с объектами и нормальной декомпозицией может возникнуть проблема с тем что какой-то граф объектов придется инстанцировать на каждый запрос. Ровно такая же проблема и, например, с коннекшенами к базе — на каждый http запрос вам надо переподключаться (а эта операция тоже дается вам не бесплатно). pconnect и т.д. позволяют решить эту проблему, но у вас может быть не только sql и там всеравно надо будет делать реконнекты.
Это я подвожу к мысли что в целом распространенная (но уже не единственная) для PHP модель выполнения приложения уже не эффективна. А пытаться "уменьшить последствия" за счет сознательного увеличения связанности кода — не думаю что в эту сторону имеет смысл инвестировать.
Насчёт коннекшенов к БД — в Java EE вроде с этим лучше, там пулы соединений. Но я бы не сказал, что среднее приложение на Java EE работает быстрее, скорее даже наоборот.
А если Вы о причинах… Ну наверное потому, что Java EE требует много памяти, поскольку там куча объектов инстанцированы и никуда не исчезают, ожидая новых запросов. И фреймворки довольно тяжёлые, много проверок, большой упор на безопасность. Несколько слоёв абстракции, несколько фреймворков взаимодействуют друг с другом. Железо же обычное, или даже хуже обычного, потому что на хорошее денег не хватает, все уходят на зарплаты программистам :D
Но это мои догадки.
поскольку там куча объектов инстанцированы и никуда не исчезают
Это не особо влияет на производительность.
Несколько слоёв абстракции
а вы думаете в современных php фреймворках по другому?
Я поверю если скажем в случае тех "сайтов" с которыми вы работали проблема была в криворукости разработчиков. Не эффективные алгоритмы, не оптимизированная база, еще какая-нибудь хрень. Но к java это не имеет никакого отношения.
Если проект небольшой, и разработчиков 1 или 2 человека — какая вообще разница.
разница в том, что если не держать связанность в узде, то рано или поздно мы придем к ситуации когда вносить изменения в код становится сложно. Вы же видели код который "проще переписать с нуля чем впилить фичу"? И мы не будем сейчас поднимать вопрос что это никогда не проще, просто вспомните то ощущение беспомощности и отвращения.
всё равно невозможно будет без ООП обходится
подавляющему большинству наличие классов в их коде не мешает обходиться без ООП (тут больше вопрос в четком определении что это такое). Вы же видели как люди active record тот же юзают. А любовь к слоям?
иначе все в «лапше» просто утонут.
А теперь представьте себе лазанью. Где люди настолько упоролись в архитектуру (без осознания что те или иные решения дают, просто прочитали пару книжек и впихнули все практики которые нашли в одно решение). Когда для добавления нового поля на UI вам надо "прорезать" все слои. При том что связанность там будет на том же уровне что и в лапшекоде на уровне wordpress. Но при этом рефакторить такой код в разы сложнее (больше зависимостей).
Люди почему-то смещают фокус с идеи (зависимости сами по себе плохо и надо уменьшать/прятать их количество всеми силами) на конкретику, которая проще в восприятии. Например луковая архитектура. Можно посмотреть, легко разобраться, не особо надо думать. А осознания плюсов и минусов, зачем… и тааак сойдет. Зато ООП.
Есть же еще, скажем, ФП, которое намного более интересно в этом плане. Там и определения четкие, и критерии изоляции функции более простые. Но на PHP с ФП сложно, язык не приспособлен для такого. А идея что хороший разработчик должен знать как минимум 3 языка (не обязательно все три на хорошем уровне, просто для расширения кругозора), почему-то считается дикой. И все сводится к обсиранию того или иного языка.
К счастью, миновало. Мой код до такой степени безобразия не доходил…
>Есть же еще, скажем, ФП, которое намного более интересно в этом плане. Там и определения четкие, и критерии изоляции функции более простые.
С большим уважением отношусь к ФП. Но во-первых, чтобы понять их в полной мере, нужна серьёзная мат. подготовка (наш препод по практике в конце второго курса, будучи уже аспирантом, нам признался, что курил вывод какой-то теоремы 2-3 ночи и еле вкурил, чтобы разобраться с монадами). А во-вторых, для практических задач… Ну вот смотрите, простой текстовый редактор. Или даже не очень простой. Его будет проще сделать на Java/C++, или на Haskell? Я ставлю на первый вариант :) Хотя на Haskell пытались. И даже делали :)
>Люди почему-то смещают фокус с идеи (зависимости сами по себе плохо и надо уменьшать/прятать их количество всеми силами) на конкретику, которая проще в восприятии.
Это да, совершенно согласен.
Мой код до такой степени безобразия не доходил…
То есть вам никогда не приходилось работать в команде над уже существующим проектом?)
Но во-первых, чтобы понять их в полной мере, нужна серьёзная мат. подготовка
на самом деле для базовых вещей — не особо. Вам не надо наизусть знать тезисы Алонзо-Черча что бы писать на F# к примеру или Scala.
Или даже не очень простой. Его будет проще сделать на Java/C++, или на Haskell?
Представим себе редактор вида google docs с возможностью колаборативного редактирования. Где несколько человек могут одновременно менять содержимое документа.
То есть по сути нам будет проще, если все изменения документа будут представлены append-only структурой данных, из маленьких имутабельных дифов, проигрывая который можно восстановить стэйт документа и предотвратить коллизии.
И знаете, Haskell тут будет эффективнее. При условии что вы знаете haskell на том же уровне что и человек который "проще бы запилил на java".
Вы же должны понимать что проблема не с тем что Haskell сложна, а со стериотипами что это сложнее чем java. Это больше проблема образования/узкого кругозора разработчиков нежели идеи/языка.
чтобы разобраться с монадами)
А вы уверены что с объектами разобрались? Там же еще сложнее — нет никаких формальных определений или принципов. Есть очень субъективные штуки и все. И проблема с ООП как раз таки в том, что в силу очень слабой формализации люди трактуют так как им привычно. При том что даже если бы большинство, которое считает что ООП это про классы, потрудились бы изучить хотя бы основы структурного проектирования — было бы проще.
Тот факт что надо потратить 2-3 ночи на изучения такой концепции как монады лишь говорит о том, насколько простая эта концепция, и насколько обманчиво простыми являются многие другие к которым вы привыкли.
Но эти субъективные штуки кажутся интуитивно проще, что поделать :)
>То есть по сути нам будет проще, если все изменения документа будут представлены append-only структурой данных, из маленьких имутабельных дифов, проигрывая который можно восстановить стэйт документа и предотвратить коллизии.
Это хорошая идея, но я не думаю, что реализовать это на традиционном ЯП через императивный подход будет сильно сложнее. Хранить список операций и проигрывать его — для решения этой задачи непременно нужно писать на функциональном языке, серьёзно?)
>Тот факт что надо потратить 2-3 ночи на изучения такой концепции как монады
Проблема не в том, что три ночи. А в том что даже для некоторых аспирантов на матмехе спбгу это трудно. А значит, идеи там правда непростые. Нам даже не стали пытаться объяснять, как это всё работает под капотом.
А вот C++ на начальном уровне сейчас уже многие школьники знают. И даже что-то пишут
кажутся интуитивно проще
ключевое слово — кажется. По факту большинство не понимает ключевых концептов для объектов (изоляция, сокрытие информации, снижение связанности).
если бы это было "интуитивно" — то небыло бы написано столько говна.
что реализовать это на традиционном ЯП через императивный подход будет сильно сложнее.
не сложнее, менее удобно, больше кода.
Если вам интересно — посмотрите вот эту лекцию: Functional architecture — The pits of success — Mark Seemann
А в том что даже для некоторых аспирантов на матмехе спбгу это трудно.
естественно что "не разбираться с вопросом" и полагать что все и так интуитивно понятно намного проще) Но это не так.
А значит, идеи там правда непростые.
Вы не поверите, но даже "класс" штука непростая. Если интересно — почитайте публикации Хоара (там где он впервые заговорил о том что сегодня называется "класс"), или Барбары Лисков.
И даже что-то пишут
и это пугает.
>и это пугает.
Вы думаете, лучше бы и не писали? Все должны с чего-то начинать)
что там нечто недоступное для осознания)
ну так монады тоже не что-то недоступное для осознания. Просто большинство принцип подстановки не понимает, ровно как и идею контрактов. А если посмотреть на обманчиво простую формулировку принципа SRP вообще может показаться что ничего сложного нет. Однако это один из самых сложных принципов.
Спасибо, обязательно :)
которое визуально врезается в память
а зачем?
Ну то есть вот серьезно, что это вам дает? Мне это говорит только о том, что такое понятие как "абстракция" в целом не понятно новичку. И как следствие через N лет мы видим очередного программиста который лепит AbstractFactoryFactory и считает что он умеет в абстракцию (потому что абстрактный класс замутил).
Мне кажется что неумение декомпозировать задачи свидетельствует о огромном фэйле системы образования.
Это для многих тяжело. Надо ведь мозг включать
а теперь представьте что у вас нет ни кассов, ни интерфейсов, ни сервисов, фабрик и всяких там "слоев" а есть просто функции и структуры данных. И в идеале все функции чистые (то есть зависят только от своих аргументов). И функции можно передавать как аргументы другим функциями (по сути late binding). И вы можете любую "грязную функцию" подменить на чистый аналог (для тестирования). И все можно протестировать. И все намного проще, нет кучи лишних терминов (функторы, фри монады и прочие теории категорий можно изучить в факультативном режиме, это не требуется для начала).
Я и не говорю, что такое — хорошо и правильно. Но что это даёт — могу сказать. Лёгкое узнавание. Понижается скорость чтения собственного кода, быстрее понимаешь, какая строчка что делает (и какой блок что делает). И чем больше в коде абстракций, фабрик и сервисов, тем ниже (для меня и для многих новичков) его читаемость.
>Мне кажется что неумение декомпозировать задачи
А если человек, предположим, умеет их декомпозировать. Что это изменит? Проблему, описанную выше, это не решит. Это уже проблема особенностей мышления конкретного человека. Тут или себя переделывать, или даже не знаю, менять профессию :)
>а теперь представьте что у вас нет ни кассов, ни интерфейсов, ни сервисов, фабрик и всяких там «слоев» а есть просто функции и структуры данных. И в идеале все функции чистые (то есть зависят только от своих аргументов). И функции можно передавать как аргументы другим функциями (по сути late binding).
Очень похоже на мой код для сайтов на JavaScript, кроме шуток. Но JS — не функциональный ЯП (хотя и имеет некоторые черты, но я лучше об этом не буду, чтобы не наговорить глупостей).
>И все можно протестировать. И все намного проще, нет кучи лишних терминов
Да, и правда намного проще. Только в чём разница вот такого кода на чистых функциях (не важно, на Haskell, Scala, Erlang или на чём), и обычного кода, который пренебрежительно называют «лапшой»? Ведь и там, и тут — куча мелких функций с низкой связностью, которые по отдельности легко тестить, но в которых можно утонуть, когда их становится много, и которые все одноуровневые (нет иерархии). Или последнее я зря сюда добавил, иерархия допустима?
composer require dshafik/php7-mysql-shim «works like a charm». Больше проблем доставили другие несовместимости между 5 и 7. Но, в целом, даже дремучее legacy за один рабочий день вполне себе втаскивается на 7.2.
АПИ там не сильно отличается, в функциональном плане.
Но отличается! Хотя бы тем, что «i» в имена функций добавили (и не только этим). Переучиваться всегда неудобно
что позволяет не писать свою обёртку
Вы про конструктор запросов?
так же там есть поддержка подготовленных запросов, что позволяет забыть о SQL инъекциях.
Вот это упустил. Пожалуй, и правда стоит её изучить получше)
Кстати, мне кажется, или кастомный код всё-таки надёжнее, чем использование подготовленных запросов? Не помню, как дела с типами параметров в этих запросах обстоят, но как минимум даже если они поддерживаются, мы можем ещё больше ограничить допустимое множество значений в кастомном коде. А там, где оно ограничено — инъекции и так практически исключены. Где требуется свободный ввод пользователем произвольного текста — ну так функции фильтрации ещё с доисторических времён существуют :)
Да это же разве переучиваться?
Да, имхо, другой порядок аргументов и их количество — это переучиваться.
вместо таскания идентификатора соединения при вызове каждого метода
Зачем его таскать? У вас больше одной базы данных используется единовременно? Насколько я знаю, если коннект один — дескриптор соединения передавать не нужно, библиотека использует текущий автоматически (если про mysql речь идёт, по крайней мере).
А раньше нужно было писать для этого объект с обёртками функций и приватным полем с коннектом.
Я вот не писал его, и всё отлично :)
И сколько нужно было спать в анабиозе, чтобы пропустить закапывание mysql и рост использования mysqli?
Я как научился использовать PHP по учебникам 2004-2005 года, так его и использую. Да, в 2012-ом смотрел новые возможности версий 5.3 и 5.4, особенности реализации ООП, трейты. Но использовать это всё как-то так и не решился :)
Это нужно было сделать лет 10 назад.
Вот здесь я вас не понял. Я про то, что можно фильтровать переданные данные ещё строже, чем их отфильтрует функция экранирования вроде mysql_real_escape_string (и это ещё безопаснее, на мой взгляд). Вы не согласны с этим разве?
она заранее знает, где строка, где число
Ага, то есть типизация значений там имеется? Это хорошо. Я, впрочем, явно всегда тип указываю (строки фильтрую через стандартную функцию, остальное — принудительно к int).
примерно до момента, когда всё это добро нужно расширять и поддерживать
Вы немного валите всё в кучу. Лапшекод — да, его поддерживать сложно, сам не раз с этим сталкивался. Не имею ничего против Ваших слов, что это — зло. Но зачем таскать дескрипторы, если коннекшн один?.. Вам что, нечего делать, как печатать лишние буковки? Или это задел на некую туманную отдалённую перспективу, когда в результате расширения системы коннекшнов станет много, и их будет целый пул? Ну так когда будет — напишете и обёртку, и менеджер пула дескрипторов, и что угодно. И желательно на ООП. А пока этого нет — зачем ерундой страдать и терять время?
Это плохо. Необходимо профессиональное развитие, если вы на этом зарабатываете. Специалист со знаниями 10-летней давности не самая востребованная вещь.
Ну почему, если мне моих знаний хватает для реализации нужных вещей?
Это вообще была отсылка к xkcd.
Я знаю, к чему была эта отсылка :) Но ведь обратные кавычки не просто так используют? А ведь я всё ещё встречаю код, где их нет: недавно вот на StackOverflow начинающий программист задавал вопрос, их там не было, да и под SQLite почему-то принято их не использовать — не знаю, это свойство СУБД их не поддерживать, или просто традиция разработки.
У вас больше одной базы данных используется единовременно?
у меня вполне может быть больше одного соединения с базой, но это в контексте php комьюнити скорее исключение из правил.
В любом случае я не очень понял вашу мысль… дискриптор на коннекшен то один но вы его явно должны задать.
Я как научился использовать PHP по учебникам 2004-2005 года, так его и использую.
то есть за ~10+ лет скоуп ваших задач никак не поменялся? Или PHP просто не так часто проскакивает в списке ваших каждодневных задач? Можете немного описать контекст использования вами PHP?
Но использовать это всё как-то так и не решился :)
Ну вот и славно, не используйте трейты.
DROP TABLE StudentsНе хочу показаться снобом, но писать имена таблиц и столбцов без обратных кавычек в качестве обрамления — имхо, моветон :)
И кстати, скорее всего, есть возможность сконфигурировать СУБД так, чтобы имена без такого обрамления не трактовались как имена таблиц и столбцов от слова «совсем». А перед отправкой запроса на сервер — банально удалять из всех строк обратные кавычки (если они не требуются нам в тексте, иначе придётся что-то придумывать). При таком раскладе инъекция тоже не сработает.
Это от «местами несовместимости», или просто возиться не хотелось?
Например если у вас сатрый комп который типа LAMP все в одном и у вас проблемы с проихводительностью, то купив два новых компа и разнеся РНР и MySQL на разные машины вы с высокой долей вероятности решите проблемы производительности за один день. Причем с доступностью облаков сегодня — это проверяется за пару часов в облаке за 2 бакса. Стоимость разработки это бич бизнеса сегодня. И еще раз — если вы будете переписывать ООП код в функциональный ради выигрыша в производительности в сложной системе, то во-первых вы с высокой степенью вероятности облажаетесь, а во вторых это будет стоить страшных денег в разы превосходящих замену железа.
На старте разработки у меня показатели равнялись 18-24 мс при первой загрузке, и 10-13 при повторных (благодаря IonCube Optimizer, и возможно, кэш MySQL запросов играл роль). Когда я померил спустя год — та же страница рендерилась уже 40-50 мс при первой загрузке (т.к. существенно усложнилась бизнес-логика системы). Страница, где генерировался живой календарь на 100 дней (без кэширования) — та вообще очень долго рендерилась, примерно под 80-90 мс. Понятное дело, был бы я поумнее — сделал бы кэш этого календаря, и скорее всего то, что я вынес часть функционала в инклюды, сильных тормозов не дало (хотя это тоже требует дополнительных обращений к диску для PHP движка, как мне кажется), проблема была в усложнении самого кода.
Получается, если бы я использовал ООП, показатели не просели бы очень существенно? :) Я не из головы просто фантазирую, а в самом деле, когда я смотрел бенчмарки производительности разных функций PHP версии не то 5.3, не то 5.4, применение конструкторов и других элементов ООП парадигмы было одним из самых узких мест. Проигрыш был в 2.5 — 3 раза примерно.
В общем, это долгая лекция. Попытаюсь еще раз объяснить. Теоретическая возможность сэкономить пару байт в памяти и пару тактов процессора на практике не выдерживает реальной конкуренции с ООП подходом по следующим причинам: скорость разработки, возможность независимой разработки модулей без потери их взаимосвязанности и взаимозаменяемости, возможность использования сторонних модулей и библиотек, простота работы в команде (где опытный разработчик уже знает как надо писать, а начинающий может легко найти документацию и best practices) так что мы снова экономим дорогое ВРЕМЯ, причем не только не разработку, но на обучение, тестирование, отладку, поиск источников проблем и т.д. Плюс как я уже говорил замена железа стоит дешевле и приносит мгновенные результаты, без необходимости заново тестировать всю систему в случае «оптимизации под память и проц»
без необходимости заново тестировать всю систему в случае «оптимизации под память и проц»
— типа оптимизировали криво, и всё поломали?
(хотя от величины проекта сильно зависит)
давайте так. плюсы дает модульность. ООП это все же про рантайм, про объекты и их взаимодействия, а не про классы и как оно там по файлам раскидано.
Модульность нас интересует только в статическом мире, в мире исходников. Поскольку именно в этом мире мы проводим большую часть времени. Нам важно иметь возможность прочитать код и понять как оно там в рантайме будет, без необходимости запускать дебаггер и трекать кто там меняет стэйт.
Язык, который мы сейчас обсуждаем, PHP имеет ряд особенностей, которые влияют на то, что мы будем воспринимать модулем. Основная из них — 2 области видимости — глобальная и локальная (на уровне функций, методов и т.д.). То есть если вы определяете переменную в файле, эта переменная автоматически доступна во всех файлах, подключенных позже. Потому файл в этом ключе мы не можем рассматривать как полноценный модуль.
Поскольку мы хотим в идеале свести расстояние от кода, который производит побочный эффект (изменяет состояние системы) до того где это состояние хранится к минимуму, нам было бы идеально описывать стэйт и код по работе с этим стэйтом в рамках одного модуля. В PHP выбор в этом плане не велик — это могут быть только классы.
Как вы дробите логику. это уже второстепенный вопрос. Основной все же — как быстро проследить сайд эффекты и предсказать как система будет вести себя в рантайме. Именно это позволяет нам быстрее и дешевле заниматься поддержкой приложения (а так же вопросом передачи знаний о проекте между разработчиками, это часто выкидывают из уравнения и потом удивляются "а почему это так сложно найти норм разработчиков… что бы выхлоп был надо что бы чел 4 месяца хотя бы плотно с кодом работал что бы разобрался что к чему".
Теоретическая возможность сэкономить пару байт в памяти и пару тактов процессора
Пара байт и пара тактов — нет. А несколько мегабайт и пара сотен или тысяча тактов? Как я писал уже в каком-то комменте, по одному из официальных бенчей разница в 2-3 раза выходила по времени отработки на ряде «тяжёлых» функций.
который используется всегда, если руки растут из правильного места
Вот здесь тоже не понял. Что нужно делать, чтобы opcache использовался?)
Сегодня, и уже давно, купить железо в 2 раза сильнее стоит в 10 раз дешевле
Это если вообще есть деньги. А если проект только начинается и в кармане ноль, а железо — слабое, что тогда? Всё равно нет смысла мучиться, т.к. выигрыш никакой?
а вы останетесь один на один со своим старым другом-серваком, на котором посыпется винт
Дело не в том, винт или SSD. Можно купить VPS на платформе виртуализации, где будут дико урезаны ресурсы по процессору и по I/O (считайте, по доступу к накопителю). А можно иметь сервер на старом нетбуке (как у меня дома), где вроде как SSD, но по скорости — вдвое хуже, чем ноутбучные винты тех лет.
Это просто другое измерение — хочется считать биты и байты — идите в Си и Ассемблер
На мой взгляд, при разработке на любом языке есть место быстрому коду, оптимизациям, эффективным алгоритмам. С Марсом — красиво, но маниловщина. Облака — тоже спорная штука) И потом, при чём тут Марс и написание сайтиков на PHP? Нашли тоже, что сравнивать.
А если работаете на РНР, то извольте разобраться зачем его изобрели и как правильно и красиво писать на выбранном языке.
В целом, понимаю Вашу логику, и в целом, теоретически, согласен. На самом деле, там действительно имели место некоторые серьёзные проблемы с производительностью ООП в пятой ветке. Всё, что я хотел от вас услышать — «в семёрке такого нет, можете расслабиться и забыть про это». Но судя по Вашим ответам, Вы или не в курсе тех проблем, или Вам пофиг. Если второе — то вообще печаль.
На мой взгляд, при разработке на любом языке есть место быстрому коду, оптимизациям, эффективным алгоритмам.
вопрос издержек на поддержку. Если "быстрый код" генерится из красивого DSL который прост и понятен — то это норм. Если вам надо "руками писать" этот быстрый код, то я нахожу это не эффективным, с учетом того что многие из проблем решаются сбором статистики выполнения и кодогенерацией в рантайме (JIT).
Существуют конечно задачи где прям максимум надо выжать, и именно там надо загоняться, но это 0.01% от задач которые решают PHP разработчики. В качестве такого примера — приходилось мне как-то кластеризацию точек на kmeans писать на PHP. Что бы можно было меньше чем за минуту пересчитать 200K точек (O(N^2)). В итоге kmeans был заменен чуть другим алгоритмом дававшим схожий по точности результат, но работавший за O(NlogN). И когда речь идет о 210^10 итераций и 210^6 итераций, та константа, где надо метод вызвать, не играет особо роли.
Но судя по Вашим ответам, Вы или не в курсе тех проблем, или Вам пофиг.
Проведите собственное исследование вопроса) И заодно попробуйте погонять то же самое на dev-master версии PHP (там уже немало оптимизаций маленьких понапихивали). И тогда уже делайте выводы. А то верить людям в интернетах — дело такое...
одна из самых быстрых
С чем вы сравниваете? Для бложика на WP 1 секунда на запрос (без кэша) это нормально. И проблема там в архитектуре а не в "ооп или не очень".
проблема в излишней сложности архитектуры и навороченности…
битрикс… архитектура… навороченность… ну ладно. Вы же понимаете что вы сравниваете производительность платформы для блогов и платформы для ecom? Попробуйте напихать плагинов в WP что бы оно походило на bitrix и сравните производительность (без кэша). А потом варниш сверху и туда и туда.
Вы полагаете, дело исключительно в обилии функционала
в универсальности. Сами понимаете что универсальное решение не может быть эффективнее специализированного. Ни в плане поддержки ни в плане производительности.
Страницы по 3-4 секунды грузились.
я видел блоги на WP где страницы столько грузились, и самописы, и на фреймворках… при схожей сложности. Видел и делал так же системы где допустимы порог отдачи контента 100ms и это более чем реальная задача для какой-нибудь симфони где все упирается в так нелюбимое вами ООП. А если загнаться те же 100ms можно превратить в 10ms. Это уже вопрос архитектуры и т.д. и для этого не надо "отказываться от ооп".
Скажите пожалуйста, а почему, на ваш взгляд, не рассматривался Yii2? Разве он настолько не популярен?
Забавно, что в бенчмарк попал Craft CMS, сделанный на Yii2, но не попал сам Yii2 :)
craftcms.com/changelog
Released on Jun 9, 2017 Updated Yii to 1.1.19.
Yii2 не упоминается здесь не разу
Да, тестировали версию 2.6, которая на Yii1. Сейчас в разработке версия 3.0, которая на Yii2.
Php7 + symfony 4. И все нужно проверять заново и на реальных задачах и с включенными кэшами и с insert в базы данных. И с 1000 конкурентных обращений. Эта статья мне понравилась не столько цифрами и выводами, сколько самим перечнем cms в которых авторы явно знают толк. Кстати если уже на то пошло не попала базовая cms от сообщества symfony — zulu
Конкурентный доступ к файлу на медленном диске всяко будет проигрывать нормальной БД.
Исчерпывающие бенчмарки PHP 5.6, 7.0, 7.1, 7.2 и HHVM (2018)