Тест стоимости вызовов в php7.3-fpm

Темы, не касающиеся фреймворка, но относящиеся к программированию в целом.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение ElisDN »

Arhat109 писал(а): 2020.11.03, 19:41 А ведь даже для пустого приветсвия грузится 90+ классов 1.5-4.5 мегабайта памяти .. ради чего? .. ради КРАСОТЫ, в ущерб функциональности. :(
Ущерба функциональности нет никакого. Так как по функциональности код работает одинаково независимо от того, красив он или нет.

Вы путаете с производительностью. Но раз хотите сверхскорости, то программируйте сайты на компилируемых асинхронных языках, где нет тормозов интерпретатора.

А так да.
Либо пишем на высокоуровневом объектном или функциональном языке. Красиво и понятно, но медленно.
Либо пишем на процедурном C с ассемблерными вставками. Быстро, но некрасиво и непонятно.

А по финансам владельцу бизнеса проще доплатить +10к рублей за лишний сервер, оставив код красивым и понятным, чем доплачивать +100к ассемблерным гуру-программистам за их сверхспособности.
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

У вас уровень аргументации из десткого сада. Извините, но без комментариев.

То, что Вы пытаетесь защитить называется проще: "заставь дурака Богу молиться он и лоб расшибет".
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение ElisDN »

Arhat109 писал(а): 2020.11.04, 23:18 У вас уровень аргументации из десткого сада. Извините, но без комментариев.
Мои аргументы за красоту:
  1. Продуманный абстрагированный DSL позволяет делать декларативный код
  2. Единый доменный язык даёт код, понятный программисту, заказчику и доменному эксперту
  3. Отделение бизнес-логики от реализации позволяет продумывать логику, не спотыкаясь на лишние детали
  4. Инкапсуляция изменчивости за интерфейсы избавляет от жёсткой привязки к инструментам
  5. Структуры вместо ассоциативных массивов снижают вероятность опечаток
  6. Интерфейсы позволяют полиморфно подменять реализации или откладывать выбор реализации на потом
  7. Ограничения работы через интерфейсы повышают дисциплину программистов
  8. Разделение по ответственностям позволяет разрабатывать каждый фрагмент отдельно
  9. Низкая связанность компонентов позволяет менять код компонента без страха сломать окружающий код
  10. Интерфейсы позволяют добавлять новую функциональность через прокси, декораторы и композицию, не влезая старый код
  11. С маленькими простыми классами удобно проверять их бизнес-логику отдельными простыми юнит-тестами без комбинаторного взрыва
  12. Со временем из 50 простых классов по 20 строк проект вырастет до 100 таких же простых классов, а один класс из 1000 строк усложнится до монстра с 2000 строк с сотнями if-ов
  13. Добавление к 50 классам нового 51-го класса с if-ом и тестом никак не ломает предыдущие классы и тесты, а добавление if-а внутрь 1000-строчного класса мгновенно ломает десяток тестов для этого мега-класса
  14. Статические анализаторы мгновенно ловят ошибки несовместимости типов
  15. Функциональные тесты за секунды находит регрессивные поломки при доработке кода
  16. Статические анализаторы и тесты за секунды находят ошибки при переходе на новую версию PHP
  17. При отсутствии анализаторов и автотестов возникает страх обновления проекта
  18. Чётко структурированный на модули и классы код экономит время на знакомство с частями проекта у нового программиста
  19. Использование готовых сторонних компонентов экономит время на разработку
  20. Использование сторонних проверенных сообществом компонентов повышает надёжность проекта
  21. Готовые компоненты пишет, обновляет и исправляет их автор и сообщество
  22. Отделённые классы можно выносить в отдельные пакеты
  23. Использование знакомых фреймворков упрощает поиск новых программистов
Ваши аргументы за скорость:
  1. Экономия серверов
Теперь есть комментарии?
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Конешно есть, ибо это всё придумыввало наше поколение для вас, все это обсуждалось и выводилось на моей памяти. :)
Мои аргументы за красоту:

Продуманный абстрагированный DSL позволяет делать декларативный код
Единый доменный язык даёт код, понятный программисту, заказчику и доменному эксперту
"С точки зрения теории, ваши рассуждения правильные, вопросов нет: явно описывается поток управления — всё красиво. Однако в проектах, где над кодом работает большая команда, такие штуки не работают — слишком сильно увеличивается порог вхождения в код. Чтобы дописать новую возможность или исправить ошибку, надо сначала разобраться с вашим подходом, понять все ваши абстракции, задать кучу вопросов коллегам и т.д. Пока пятый сотрудник научится этим добром пользоваться, первый уже застрелится."
Отделение бизнес-логики от реализации позволяет продумывать логику, не спотыкаясь на лишние детали
Бизнес логика отделяется от реализации .. в ПРИЛОЖЕНИИ разработчика. Сочинять слой "бизнес-логики" в ИНСТРУМЕНТЕ для него - есть ненужная избыточность и снижение КПД реализации.
Инкапсуляция изменчивости за интерфейсы избавляет от жёсткой привязки к инструментам
Словоблудие чистой воды в отношении к фреймворкам. Вы много назовете рабочих проектов (Приложений), которые легко мигрируют с Yii1 на Yii2, Zend1,2, Laravel, Symphony? Да даже наличие драйверов PDO ни разу не упрощает миграцию скажем с MySQL на MS Server!
это чистая демагогия.
Структуры вместо ассоциативных массивов снижают вероятность опечаток
В PHP ассоциативный массив и есть структура. Иных нет. Динамическое создание свойств к объектам ни разу не снижает вероятность ошибок при опечатках. Больше того! массивы и объекты в PHP по большому счету одно и тоже или условно "синтаксический сахар"..
К вероятности опечаток не имеет никакого отношения, впрочем.
Интерфейсы позволяют полиморфно подменять реализации или откладывать выбор реализации на потом
В теории. На практике возникает сермяжный вопрос до какой степени дробить на интерфейсы? До одного метода?
Это как раз то самое место "заставь .." :)
Ограничения работы через интерфейсы повышают дисциплину программистов
Демагогия, призванная завуалировать низкий уровень разработчика и переплачивать ему в ЗП. Ибо дисциплина программиста и есть значительная часть его "уровня".
Разделение по ответственностям позволяет разрабатывать каждый фрагмент отдельно
Низкая связанность компонентов позволяет менять код компонента без страха сломать окружающий код
Конечно. Только к обсуждаемому вопросу отношения не имеет. Равно применимо как к глубокой ООП разработке так и работе в "чистых глобалах". Ниочем.
Интерфейсы позволяют добавлять новую функциональность через прокси, декораторы и композицию, не влезая старый код
Не смешите. Ровно точно также это все можно делать и без интерфейсов и вообще без ООП. Все эти декораторы, прокси и пр. "паттерны" есть не что иное как добавление очередного уровня косвенности в код, за который платим и очень дорого.
Грамотное проектирование архитектуры приложения, ориентированная на его развитие исключает все это чуть больше чем полностью.
То есть Вы опять ратуете за низкий уровень разработчика.
С маленькими простыми классами удобно проверять их бизнес-логику отдельными простыми юнит-тестами без комбинаторного взрыва
Никак не зависит от размера класса. Просто "лапша на уши". Класс, в котором 20 методов по 2 строки, даже сложнее покрыть тестами, чем класс имеющий 2 метода по 20 строк. Их банально надо писать больше.
Со временем из 50 простых классов по 20 строк проект вырастет до 100 таких же простых классов, а один класс из 1000 строк усложнится до монстра с 2000 строк с сотнями if-ов
Добавление к 50 классам нового 51-го класса с if-ом и тестом никак не ломает предыдущие классы и тесты, а добавление if-а внутрь 1000-строчного класса мгновенно ломает десяток тестов для этого мега-класса
Статические анализаторы мгновенно ловят ошибки несовместимости типов
Функциональные тесты за секунды находит регрессивные поломки при доработке кода
Статические анализаторы и тесты за секунды находят ошибки при переходе на новую версию PHP
При отсутствии анализаторов и автотестов возникает страх обновления проекта
Чётко структурированный на модули и классы код экономит время на знакомство с частями проекта у нового программиста
Использование готовых сторонних компонентов экономит время на разработку
Использование сторонних проверенных сообществом компонентов повышает надёжность проекта
Готовые компоненты пишет, обновляет и исправляет их автор и сообщество
Отделённые классы можно выносить в отдельные пакеты
Использование знакомых фреймворков упрощает поиск новых программистов
Может Вы их просто писать не умеете? "Большие классы" :)

Можно и детальней, но не так много времени. В целом, ваш набор аргументов - типичен, и не раз обсуждался в Сети. По большей части он связан не с работой команды, а с низким уровнем её участников, когда разраб не способен понять что делает функция в 50 строк кода, и разбивает ее на десяток по 5 строк. Со временем, такое решение разрастается в 100500 классов "ниочем", возникает проблема "сочинить имя ещё одному действию, свойству", в какой интерфейс, класс, хелпер, сервис запихать новый метод .. и т.д.
В реальности, все часто как раз наоборот: одна большая и полностью законченная функция используется в работе гораздо легче чем 100500 её мелких аналогов. Тупо объем требуемого запоминания меньше. И, как ни странно, это также хорошо видно в автопроме: один большой гелентваген удобней в управлении чем лисапед, на котором надо ещё уметь равновесие удерживать.
Но именно подход с аргументами выше - это простоение 100500 мелких лисапедов и объявление их "большим фреймворком".

Истина - посередине. И эта середина определяется из нагрузочных и потребительских требований, а вовсе не "теорией покрытия каждой функции своим интерфейсом". Как раз из такой середины, ещё в 80-х годах прошлого веку и была выведена рекомендация на размер функции в 50 строк. Это - ОПТИМУМ как для исполнителя (PHP в данном случае), так и для писателя (разработчика).
Специально, для вас выводилось.. :)
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
BalykhinAS
Сообщения: 179
Зарегистрирован: 2018.02.05, 13:41
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение BalykhinAS »

Arhat109 писал(а): 2020.11.05, 13:19 Однако в проектах, где над кодом работает большая команда, такие штуки не работают — слишком сильно увеличивается порог вхождения в код. Чтобы дописать новую возможность или исправить ошибку, надо сначала разобраться с вашим подходом, понять все ваши абстракции, задать кучу вопросов коллегам и т.д. Пока пятый сотрудник научится этим добром пользоваться, первый уже застрелится."

Возникает вопрос - как большой команде с низким порогом доверили проект который требует много разработчиков?))) Просто собрали толпу ранее не работающих друг с другом людей и сказали - пишите!) Разработка силой таких богатырей закончится ровно через 3-4 двухнедельных спринта так как они погрязнут в if else. Будет быстрый старт, и болезненный финал)) Как БОЛЬШАЯ команда может работать над одним классом в 10 000 строк? Слышал про парное программирование, но тут будет последовательное или поочередное, посменное, вахтовым методом программирование.

Подход Дмитрия практикуется, это не сказки об идеальном мире.

Разделение ответственностей, декомпозиция в этом ведь и есть смысл снижения сложности. Вы ведь не работает сразу со всеми 10 000 срок кода супер класса, в каждом конкретном случае необходимо внести правки в отвественности конкретного участка кода. Так для чего держать весь код в одной куче?
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение chungachguk »

Wizard писал(а): 2020.11.06, 14:06Так для чего держать весь код в одной куче?
прост
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Возникает вопрос - как большой команде с низким порогом доверили проект который требует много разработчиков?))) Просто собрали толпу ранее не работающих друг с другом людей и сказали - пишите!) Разработка силой таких богатырей закончится ровно через 3-4 двухнедельных спринта так как они погрязнут в if else. Будет быстрый старт, и болезненный финал))

Как БОЛЬШАЯ команда может работать над одним классом в 10 000 строк?
Передерг и влажные фантазии. Без комментариев.
Слышал про парное программирование, но тут будет последовательное или поочередное, посменное, вахтовым методом программирование.
Ну вот, возможно, в этом и дело, что только слышали. Попрактикуйте, очень интересное занятие. У IBM называлось (не знаю как там сейчас) "Хирургическая бригада". Только там 3-4 участника для двух хирургов.
Подход Дмитрия практикуется, это не сказки об идеальном мире.
Конечно. Кто бы сомневался. Снова стало мало времени, т.к. снова позвали "улучшить" развесистую архитектуру обратного управления на депенденси .. тупит как-то. Подобрал "второго хирурга" уже. :)
Разделение ответственностей, декомпозиция в этом ведь и есть смысл снижения сложности. Вы ведь не работает сразу со всеми 10 000 срок кода супер класса, в каждом конкретном случае необходимо внести правки в отвественности конкретного участка кода. Так для чего держать весь код в одной куче?
Браво! Только лоб об пол не разбейте, когда молиться будете.. речь не за то, что это плохо, а за то что всему нужна СВОЯ МЕРА.

И критерий этой меры .. те самые 50 строк на метод. Ок, с учетом всеобщей деградации, пусть будет 30. :)
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
BalykhinAS
Сообщения: 179
Зарегистрирован: 2018.02.05, 13:41
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение BalykhinAS »

О мере с вами и спорить не буду. Она нужна во всем. И в убежденности в своей правоте тоже кстати мера нужна. Но классы на 10000 строк то к чему? Это соблюдение меры? У вас есть примеры таких классов? Если нет, то разговор не предметный и больше похоже на теоретический трёп.

Я работаю с легаси по 5к строк и похоже это на кусок говна после которого на ооп действительно молиться хочется. Очевидно мало опыта и не доводилось видеть суперклассы которые можно с лёгкостью поддерживать, которые можно назвать удачной альтернативой декомпозиции на подклассы

Неужели все методы этого монстра действительно разбиты на 50 строк кода и все они являются неотъемлемой частью этого класса и при этом остаётся очевидность, удобство сопровождения. Невероятно, поверить не могу) неубетительно как то звучит, сыровато.
BalykhinAS
Сообщения: 179
Зарегистрирован: 2018.02.05, 13:41
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение BalykhinAS »

Почему то часто встречаю теоретиков- адептов лапшекода но теории на примерах ни разу не видел, подтверждающие их правоту. Ну очевидно arhat109 не из их числа, чувствуется какая то уверенность. Разбейте на примеры все иллюзии ооп-ешников а то от молитв лоб болит, нужна срочно альтернатива
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Wizard писал(а): 2020.11.06, 20:35 О мере с вами и спорить не буду. Она нужна во всем. И в убежденности в своей правоте тоже кстати мера нужна.
Так весь разговор как раз за МЕРУ! .. 3 предложения, противоречащие сами себе... :)
Но классы на 10000 строк то к чему? Это соблюдение меры? У вас есть примеры таких классов?
Вы так настойчиво ратуете за классы в 10тыщ строк, уже второй раз .. не читатель, или фантазия не унимается? Может Вы процитируете меня за эти 10тыщ .. или прекратите словоблудить.
Если нет, то разговор не предметный и больше похоже на теоретический трёп.
Не читали первую страницу? Там все есть. Даже исходник. Вы даже сами можете его потестировать на своем железе, возможно у Вас получатся иные цифирьки. Там ВСЁ ЕСТЬ, в том смысле, что всё остальное обсуждение идет опираясь на них и обосновано ими.
Если этого не достаточно, то никакой пример Вам не поможет.
Я работаю с легаси по 5к строк и похоже это на кусок говна после которого на ооп действительно молиться хочется. Очевидно мало опыта и не доводилось видеть суперклассы которые можно с лёгкостью поддерживать, которые можно назвать удачной альтернативой декомпозиции на подклассы

Неужели все методы этого монстра действительно разбиты на 50 строк кода и все они являются неотъемлемой частью этого класса и при этом остаётся очевидность, удобство сопровождения. Невероятно, поверить не могу) неубетительно как то звучит, сыровато.
Ваш опыт, безусловно ценен, но в ИТ также много опыта, где декомпозиция доведена до абсурда в виде интерфейса на КАЖДЫЙ метод + абстрактного класса на пару и обязательно приватных свойств с геттерами и сеттерами с подключением магии и с финальными классами на 10-20 уровне наследования, ибо "бизнес-логику" никто не отменял.

Вы просто не видели реально большой проект на 100 тысяч классов по 30 строк кода каждый, где каждый чих имеет свой сервис, пара сервисов уже имеет менеджера сервисов с хелпером, а тройка менеджеров имеет свою фабрику и все это под событиями и поведениями "до, после, вместо, .." запуска самого чиха с пробросом параметров настройки через весь звездолет, т.к. никому больше они в реале не нужны, кроме бизнес-чиха.
В моем резюме в сентябре как раз была ссылка, на кусок такого проекта, где парсер ЭДО как раз начинался с обратного управления, пробрасывая конфигуратором описание формата документа в xml-сборщик ЭДО, который в терминологии современного ООП есть не что иное как брокер фабрик-построителей методов вывода каждой отдельной(!) строчки ЭДО своей группой сервисов с ровно одной реализацией реального класса-построителя (чих - класс из одного присваивания - сеттера).
.. 45 классов (интерфейсов + трейтов) были заменены на 1 класс - генератор документа ЭДО размером в .. около 400 строк кода (включая ок 30% документирование). Забавно то, что суммарный размер кода этих 45 классов, после копипаста в один файл, даже с обрамлениями занял .. всего чуть большще 600 строк.

P.S. И да, подзабыл, в силу того, что в 2020г было уже третье изменение правил ЭДО, то .. таких папок в проекте было .. ага, ДВЕ штуки. Вот и весь сказ за "полиморфность", ценность обратного управления и т.д. Разрабу, оказалось ПРОЩЕ скопипастить весь вертолет, чем разбираться ГДЕ правильно поменять правила.

ЭТО И ЕСТЬ "Заставь дурака Богу молиться" и "ИСТИНА посередине".. о каких 10 тыщах строк в классе Вы все время сокрушаетесь - мне неведомо.
И таки да, тоже видел большой сайт, написанный в виде ОДНОГО файла. 20-30 тыс. строк кода, не помню.. давно было. Вполне читаемо, разбираемо, ибо написано было МОДУЛЬНО. Просто собрано в один файлик. Большой, неудобно .. и только.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

О чем данный топик? (в третий раз!)

1. Показано, что вызов функции (метода, статики, лямбда) в любом интерпретаторе есть САМАЯ ДОРОГАЯ операция. (может приводить к поеданию памяти, но это не из этой оперы - отложим).

2. Введено понятие "КПД интерпретатора" как отношение полезной работы в коде Приложений, к общим затратам на исполнение процессором всего кода, в т.ч. и самого интерпретатора. В качестве подопытного кролика тут выступил PHP7.3 как "самый шустрый", и претендующий на высокое КПД.

3. На основе тестирования, показано что PHP7.3 может иметь достаточно высокий КПД от 50%, при условии достижения размера функции не менее 30 исполняемых действий (строк) на тело функции. Рекомендованная ранее (в 60-80х) "норма" в 50 строк, поддерживает этот вывод, но ограничивает размер сверху, из-за сложности восприятия "разрывов" в процессе просмотра (влезать на 1 экран, страницу печатного документа и т.д. - то есть "быть обозримой за раз")

Отсюда:
3а) линейная функция, далеко не всегда должна разбиваться на "этапы", в ситуации отсутствия "нужности" самих этапов по отдельности. Только при превышении требований к размеру тела функции.
3б) кол-во параметров вызова есть важный момент, и их не должно быть слишком много (ранее рекомендовалось не более 3-х, теперь понятно зачем).

из обсуждения далее:
4. Паттерны проектирования, предназначенные улучшить сопровождение легаси (обратное управление и всё что с ним связано), обязаны применяться вдумчиво, т.к. их реализация - это ВСЕГДА введение дополнительного уровня косвенности, через вызов функций. Зачастую 2-3 уровня. Возможно, требуется поиск ИНЫХ решений, как пример, возврата к простому хранению одной косвенности в переменной (статике класса, в т.ч.)

5. Приватность, геттеры, сеттеры, магия при простом присваивании есть дорогая избыточность, которую можно применять исключительно ОБОСНОВАНО бизнес-локигой Приложений.

6. В проектах "общего назначения" (фреймворках), стоит особо внимательно следить за ростом декомпозиции, т.к. их "бизнес-логика" жестко фиксирована конректикой назначения элементов фреймворка.

В целом, утверждается, что переход от полностью монолитного решения (один файл) к полностью декомпозированному решению (один интерфейс на метод + 1 абстрактный класс на свойство) имеет ОПТИМУМ (Истина - посередине) и, каждое движение туда-обратно должно ОБОСНОВЫВАТЬСЯ в проекте.

Процесс обоснования должен соблюдать выше изложенные особенности КПД интерпретаторов. То есть, рекомендации ООП для компилируемых и глубоко оптимизируемых языков (C, Delphi, Java, C++, etc.) становятся НЕ ПРИМЕНИМЫ для интерпретируемых языков (JS, PHP, Python, ..)
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

P.P.S. Применение изложенного для фреймворков "сайтописательства" (Yii в частности) должно снизить требования к памяти до 100 раз, и повысить скорость отдачи страниц в десятки раз .. 20 к примеру.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение samdark »

Вроде как в третьей версии от ActiveRecord отказались .. а как дела со множественной вставкой?
Батч-insert есть в Yii 2. В Yii 3 будет AR, портированный из Yii 2. Просто не сразу.
P.S. Сорри, ссыль обрезана, не попасть...
https://github.com/yiisoft/docs/blob/ma ... drunner.md
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Спасибо. Так и подумал что Вы про связку с Go. Вот тут было хорошо расписано, и Ваш скрипт запуска Yii2 аналогичен:
https://habr.com/ru/company/badoo/blog/434272/

Да, в такой конфигурации Вы избавитесь от "умирания PHP скрипта", а вынеся создание приложения за цикл, получаете его "долгоживущий вариант", срезающий затраты на бутстрат фреймворка. .. но и только. :)
Это то самое место, где писал выше - "нашел узкое место, можно ещё ускорить" .. да,да: устранить "умирание", и избежать загрузки файлов.

Разница в "2, может 3" раза, у моей "пародии на Зенд" и ваших "до 40раз" она как раз связана с количеством работающих классов в бутстрапе фреймворка. Ок. С этой частью справится условно можно, есть решение.

Но это же только половина проблемы! :)

Проблема, озвученная в самом начале значительно ширее :)
А именно, Вы никак не избавитесь от геттеров, сеттеров, многослойной иерархии классов и всё это так и продолжит тянуть за собой снижение общего КПД, ибо PHP - интерпретатор.

Процитирую сам себя:
P.P.S. Применение изложенного для фреймворков "сайтописательства" (Yii в частности) должно снизить требования к памяти до 100 раз, и повысить скорость отдачи страниц в десятки раз .. 20 к примеру.
Изменение ускорения от RoadRunner: 40/2 как раз и даст оценку в 20 раз.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Ну и ещё. Внедрение зависимостей происходит на уровне работы бутстрапа, то есть .. приложение разворачивает свои синглтоны, статику классов и т.д. ДО этого цикла и всё это с одной стороны улучшает жизнь приложения, а с другой .. требует ИНОГО подхода к его разработке в целом. Много народу, кто осознает что это важно? А с учетом того, что даже в "построитель запросов Yii2" мало кто ныряет?
:)
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Ответить