it-swarm.com.ru

Очистка WordPress для повышения производительности?

Если посмотреть на текущую кодовую базу WordPress, становится ясно, что функции используются слишком часто. Я считаю, что более 8 100 функций/методов определены в базе кода WordPress. Это ужасное и ужасное использование ресурсов.

Проблема с таким количеством функций (или классов) заключается в том, что wordpress не является DRY (не повторяйте себя), и я уверен, что многие из этих блоков могут быть объединены или заменены лучшими шаблонами .

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

Решение?

PHP 5 & 6 имеет SPL автозагрузку классов. Это функция, которая позволяет PHP ждать, пока ему не понадобится класс, прежде чем загружать его. Это предотвращает потерю ресурсов , так как неиспользуемые функции/файлы не загружаются, пока они не понадобятся.

К сожалению, WordPress не может использовать это, потому что "автозагрузка" в PHP работает только для классов .. а WordPress - это набор функций.

Я смотрю на варианты и проблемы для очистки базы кода WordPress, и это, кажется, самый большой.

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

Единственная идея, которую мне удалось придумать, - это написать скрипт, который бы просматривал все функции и преобразовывал их в классы, которые затем можно было бы автоматически загружать. На их месте остались бы функции Shell, называемые классовой версией функции.

Что-то вроде этого:

function wp_foo_bar() {
    call_user_func_array(array('foo' => __FUNCTION__), func_get_args());
}

Кто-нибудь еще пытался очистить базу кода WordPress? Есть ли другие проблемы с этим подходом?

Обновление для уточнения

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

Если мы остановимся здесь - тогда мы можем потерять производительность, потому что у нас одинаковое количество функций - и теперь классы также начинают загружаться автоматически.

Следовательно, это не имеет ничего общего с процедурным кодом vs OOP . Это лучший способ защитить API от изменений в системе в целом. Текущая команда разработчиков WordPress уже делает это в очень медленном темпе. В системе WordPress уже более 60 классов.

6
Xeoncross

Вы действуете на очень большом предположении, что что-то подобное улучшит производительность. Спойлер - нет, не будет.

Процесс загрузкив очень рыхлом выражениисостоит из:

  1. Опционально работает код, отвечающий за поиск определений (автозагрузка или пользовательский).
  2. Анализ файла или получение результатов из кэша кода операции.
  3. Загрузка результатов для использования.

"Автозагрузка быстра" - распространенная ошибка. Передовая автозагрузка - этоудобно. На самом деле это можетзамедлить процессна практике, потому что обработка файлов значительно улучшена за счет кэша кода операции, но многократноопределение местонахожденияэти файлы (шаг 1) оптимизирован до сих пор и складывается очень быстро.

Пользуется ли ядро ​​WordPress преимуществами лучшей организации и автозагрузки классов? Конечно, этого не происходит, потому что он разработан на основе неиспользования этой возможности PHP.

Но "преобразование" функций в автозагрузку классов? Мое обоснованное предположение, что это ухудшит производительность, пытаясь оптимизировать часть процесса, которая не является узким местом на первом месте (в текущем состоянии основного кода/нагрузки).

13
Rarst

функционально интерпретируемый код всегда будет быстрее, чем OOP one. сравнить

function hello_mark() {
  echo 'hello mark';
}

hello_mark();

с

class mark {
  function say_hi() {
    echo 'hello mark';
  }
}

$m = new mark();
$m->say_hi();

Я думаю, что очевидно, что быстрее интерпретировать и выполнить.

Люди не делают OOP, потому что это быстрее, они делают это, потому что это лучше представляет "проблемную область" и создает более простой в обслуживании код.

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

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

В любом случае, просто потому что есть много функций, которые не загружаются лениво, это не означает, что даже при ленивой загрузке они не будут загружены к тому времени, когда wordpress завершит свою инициализацию. Отдать должное разработчикам ядра за то, что они достаточно хорошо знают язык, чтобы иметь возможность помещать функции, которые не нужны для инициализации, в свои собственные файлы всякий раз, когда это не нарушает логическую структуру программного обеспечения (т. е. глупо update_option в другом файле, чем delete_option только потому, что delete_option не вызывается во время инициализации)

9
Mark Kaplun

Удачи вам, но это никак не улучшит производительность.

WordPress действительно становится все более объектно-ориентированным, со временем и с постепенными изменениями. Каждое обновление за последние 4 года преобразовывало некоторые основные части кода в более ориентированный на класс дизайн.

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

ООП в целом это другой способ организации в программировании. Это более разумный и чистый подход для многих случаев. Но по сути это не "лучше", и на самом деле он заметно медленнее и требует больше памяти почти во всех реальных сценариях, или в лучшем случае это безубыточность. Модель OOP обычно предпочтительнее, потому что а) она проще в обслуживании и тестировании кода, б) во многих школах она преподается как "правильный" способ, и в) программисты - это те люди, которые нравится создавать модели вещей. OOP хорошо вписывается в этот "модельный" менталитет. Представьте "вещь", используя один кусок кода, затем пусть ваши "вещи" взаимодействуют с другими "вещами", такими как соединение частей lego. Аккуратный, чистый, аккуратный. :)

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

Можете ли вы написать код, чтобы переместить весь код в классы, а затем сделать функции простыми хуками в эти классы? Конечно, наверное. Что это поможет? Ничего существенного.

Чтобы удовлетворить ваши конкретные желания:

Гораздо сложнее обесценивать функции. Поэтому этот вопрос начинается с начала переписывания системы.

Во-первых, я думаю, что вы имели в виду "не одобряйте".

Во-вторых, вы не можете переписать все целиком и достичь своих целей. В этом вся моя суть. Вернитесь и посмотрите на 3.1 или 3.2. Теперь посмотрим на 4.0. Обратите внимание на количество классов и то, как они действительно подвергаются рефакторингу с течением времени.

Нет смысла тратить кучу времени на переписывание рабочего кода только для того, чтобы получить те же результаты, если только вы не собираетесь реально улучшить его в процессе. Поскольку каждая часть в WordPress улучшается, она обычно превращается в систему класса/ООП. Постепенная эволюция. Изменяйте со временем, чтобы позволить старым плагинам исчезнуть и создать новый код для его поддержки и исправления и тому подобное. Вы не можете разрушить мир в одночасье и ожидать, что все последуют за вами, вы должны изменить вещи медленно и методично.

7
Otto

@Xeoncross,

Вы пишете в своем профиле WP Dev

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

Это все хорошо для приложения, вашего приложения или приложения, над которым вы работаете; или ваша собственная философия и методы программирования.

Но Wordpress - это сообщество, и как таковое работает по-другому. Он может пожертвовать (из-за отсутствия лучшего слова) вещами с точки зрения структур программирования, языков и эффективности, которые являются приоритетами для небольших или индивидуальных проектов.

Но Wordpress выигрывает в результате существования сообщества. Экосистема велика и разнообразна, развитие развивается, и в результате - или, несмотря на это, WordPress очень популярен.

Как сообщество, Wordpress не может действовать так же, как отдельный проект или разработчик.

Вы сравниваете яблоки и апельсины, а также деревья, на которых они растут, и людей, которые любят яблоки лучше, чем апельсины.

Я не считаю себя программистом, и я не могу спорить о преимуществах и преимуществах ООП, классов, процедур и так далее.

1
markratledge