Предлагаю в этой теме собирать (с последующим устранением) координаты избыточных(ненужных) участков кода
| Dayver |
|
|---|---|
|
Предлагаю устранить (прежде проверив на 100% действительно ли такие куски php кода в движке не нужны и их удаление не повлечет за собой ошибок) такие избыточные строки кода: - Итак для генерации страницы по url /index.php?e=page&id=XXX&m=edit происходят следующие цепочки инклудов php файлов API разного полезного функционала (их повторение не вызывает ошибок поскольку используется функция require_once):
потому убрав в /modules/page/page.php строку 25; в /modules/page/inc/page.functions.php строки 17, 18; в /modules/page/inc/page.edit.php строку 14 мы, по идее, избавимся от ненужных вызовов функции require_once ибо это избыточно (наверняка оптимизация "спичечная" но код станет чище). - Такая же, аналогичная, ситуация и по урлу /index.php?e=page&c=XXX&m=add - Да и вообще много где в расширениях идет вызов, например, /system/extrafields.php хотя он итак уже включен в /system/common.php который предшествует любому файлу модуля или плагина
Может я где то чего не доглядел или не допонял но все вроде так работает - так зачем плодить лишние строки кода и вызовов функций?! Добавлено 4 часа спустя: К тому же еще вопрос - зачем в корневом index.php инклуды (файлов config.php, functions.php, cotemplate.php, common.php) идут посредством require_once, а не просто require ведь "выше" него уже нет ничего, а потому вероятность того что эти файлы уже были подлючены практически нулевая потому зачем лишние проверки? Та же ситуация в common.php.
Pavlo Tkachenko aka Dayver
|
|
Dit bericht is bewerkt door Dayver (2012-06-23 12:07, 13 jaren ago) |
| esclkm |
|
|---|---|
|
согласен с тем - что надо логику загрузки файлов создать - и если файл загружен в любом случае - зачем его грузить еще раз littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Dayver |
|
|---|---|
|
А еще мне кажется что все эти библиотеки API нужно просто взять за правило подключать (ели оно глобальное например как кеш или экстраполя и формы) к примеру только в common.php (естесно ведя спец параметр в datas/config.php которым разработчик сможет отключать все это при необходимости) .... и тогда в расширениях не придется по десять раз инклудить .... а если расширению требуется свой библиотека или API то подключать ее в том же common.php с помощью хука (например input или global) Pavlo Tkachenko aka Dayver
|
| Macik |
|
|---|---|
#34759 Dayver:
В общем согласен - избыточность убирать надо. Но что касается все вызовы перенести в «common» - тут вопрос, что «дороже» будет: перекроет ли экономия от обрезания require_once затраты на лишний цикл хуков для каждого из модулей который хочет загрузить свою библиотеку. Строго говоря, надо запустить профайлер и посмотреть сколько «сжирает» require_once как в примере выше и посмотреть какой это процент от общих расходов. И думается мне, что в топе будут совсем другие вещи, которые можно (и нужно) оптимизировать.
Добавлено 3 минуты спустя: да к тому же приведенный пример (ссылка) не очень актуален, т.к. это режим редактирования - его вызывает ограниченное количество пользователей, ограниченное количество раз. Т.е. это скорее «режим админки» там скорость менее важна, чем на вызове страниц или категорий. Добавлено 3 недели спустя: В продолжение темы: настроил у себя на локальной машине расширение для PHP: «Inclued». Оно собирает статистику по подключению модулей к проекту и создает массив. Потом его можно преобразовать в графическую схему. Вот для примера: https://s3-eu-west-1.amazonaws.com/static.galaxyhost.org/cotonti/cotonti_inclued.png (1,1Мб 4300х3400 pix) Это схема вызово модулей для главной страницы Котонти (почти стандартная установлка из коробки, просто для примера). Сплошные линии это первичный вызов файла. Пунктирные это повторное обращение к файлу. Можно медитировать. https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
|
Dit bericht is bewerkt door Macik (2012-09-14 21:51, 12 jaren ago) |
