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

<p>если посмотреть на текущую кодовую базу wordpress, становится ясно, что функции используются слишком часто. я считаю, что более 8 100 функций/методов определены в базе кода wordpress. это ужасное и ужасное использование ресурсов.</p><p><strong>проблема с таким количеством функций (или классов) заключается в том, что wordpress не является dry (не повторяйте себя), и я уверен, что многие из этих блоков могут быть объединены или заменены лучшими шаблонами .</strong></p><p>тем не менее, нам нужно каким-то образом буферизовать текущий api (все эти функции), чтобы мы могли начать комбинировать код бэкэнда без изменения "интерфейса" (используется свободно).</p><h3>решение?</h3><p>php 5 & 6 имеет spl автозагрузку классов. это функция, которая позволяет php ждать, пока ему не понадобится класс, прежде чем загружать его. это <a href="https://github.com/wordpress/wordpress/blob/69be1c682fd51c7a5ca85806c5b85b8a3e162a4b/wp-settings.php#l111">предотвращает потерю ресурсов</a> , так как неиспользуемые функции/файлы не загружаются, пока они не понадобятся.</p><p>к сожалению, wordpress не может использовать это, потому что "автозагрузка" в php работает только для классов .. а wordpress - это набор функций.</p><p>я смотрю на варианты и проблемы для очистки базы кода wordpress, и это, кажется, самый большой.</p><p>поскольку wordpress создал так много функций (вместо того, чтобы выставлять классы) для разработчиков плагинов/тем, кажется, нет никакого способа вырваться из этой глубокой дыры, не нарушая тысячи тем и плагинов.</p><p>единственная идея, которую мне удалось придумать, - это написать скрипт, который бы просматривал все функции и преобразовывал их в классы, которые затем можно было бы автоматически загружать. на их месте остались бы функции shell, называемые классовой версией функции.</p><p>что-то вроде этого:</p><pre><code>function wp\_foo\_bar() { call\_user\_func\_array(array('foo' => \_\_function\_\_), func\_get\_args()); } </code></pre><p>кто-нибудь еще пытался очистить базу кода wordpress? есть ли другие проблемы с этим подходом?</p><h3>обновление для уточнения</h3><p>преобразование системы для использования автозагрузки - это первый шаг, который позволяет нам лучше контролировать загрузку ресурсов и выстраивать фасады по мере того, как мы переводим некоторые основные функции в более совершенные проекты. гораздо сложнее обесценивать функции. поэтому этот вопрос начинается с начала переписывания системы.</p><p>если мы остановимся здесь - тогда мы можем потерять производительность, потому что у нас одинаковое количество функций - и теперь классы также начинают загружаться автоматически.</p><p>следовательно,<em> это не имеет ничего общего с процедурным кодом vs oop </em>. это лучший способ защитить api от изменений в системе в целом. текущая команда разработчиков wordpress уже делает это в очень медленном темпе. в системе wordpress уже более 60 классов.</p>

<p>вы действуете на очень большом предположении, что что-то подобное улучшит производительность. спойлер - нет, не будет.</p><p>процесс загрузки<em>в очень рыхлом выражении</em>состоит из:</p><ol> <li>опционально работает код, отвечающий за поиск определений (автозагрузка или пользовательский).</li> <li>анализ файла или получение результатов из кэша кода операции.</li> <li>загрузка результатов для использования.</li> </ol><p>"автозагрузка быстра" - распространенная ошибка. передовая автозагрузка - это<em>удобно</em>. на самом деле это может<em>замедлить процесс</em>на практике, потому что обработка файлов значительно улучшена за счет кэша кода операции, но многократно<em>определение местонахождения</em>эти файлы (шаг 1) оптимизирован до сих пор и складывается очень быстро.</p><p>пользуется ли ядро wordpress преимуществами лучшей организации и автозагрузки классов? конечно, этого не происходит, потому что он разработан на основе неиспользования этой возможности php.</p><p>но "преобразование" функций в автозагрузку классов? мое обоснованное предположение, что это ухудшит производительность, пытаясь оптимизировать часть процесса, которая не является узким местом на первом месте (в текущем состоянии основного кода/нагрузки).</p>

<p>функционально интерпретируемый код всегда будет быстрее, чем oop one. сравнить</p><pre><code>function hello\_mark() { echo 'hello mark'; } hello\_mark(); </code></pre><p>с</p><pre><code>class mark { function say\_hi() { echo 'hello mark'; } } $m = new mark(); $m->say\_hi(); </code></pre><p>я думаю, что очевидно, что быстрее интерпретировать и выполнить.</p><p>люди не делают oop, потому что это быстрее, они делают это, потому что это лучше представляет "проблемную область" и создает более простой в обслуживании код.</p><p>код должен быть организован таким образом, чтобы его было легче поддерживать и разрабатывать, чтобы всегда можно было использовать более совершенных интерпретаторов, или компилировать в машинный код, или, как хип-хоп facebook, уменьшить возможности языка, который вы поддерживаете, и интегрировать веб-сервер в ваш переводчик.</p><p>в частности, для wordpress на скорость сайта больше всего влияет качество кеширования. никакие улучшения в коде php не дадут вам такого же прироста производительности, как при использовании объектного кэширования.</p><p>в любом случае, просто потому что есть много функций, которые не загружаются лениво, это не означает, что даже при ленивой загрузке они не будут загружены к тому времени, когда wordpress завершит свою инициализацию. отдать должное разработчикам ядра за то, что они достаточно хорошо знают язык, чтобы иметь возможность помещать функции, которые не нужны для инициализации, в свои собственные файлы всякий раз, когда это не нарушает логическую структуру программного обеспечения (т. е. глупо update\_option в другом файле, чем delete\_option только потому, что delete\_option не вызывается во время инициализации)</p>

<p>удачи вам, но это никак не улучшит производительность.</p><p>wordpress действительно становится все более объектно-ориентированным, со временем и с постепенными изменениями. каждое обновление за последние 4 года преобразовывало некоторые основные части кода в более ориентированный на класс дизайн.</p><p>тем не менее, oo, автозагрузка и другие подобные вещи не являются "быстрее" и не являются "лучше". не беспокойтесь, это распространенная ошибка.</p><p>ооп в целом это другой способ организации в программировании. это более разумный и чистый подход для многих случаев. но по сути это не "лучше", и на самом деле он заметно медленнее и требует больше памяти почти во всех реальных сценариях, или в лучшем случае это безубыточность. модель oop обычно предпочтительнее, потому что а) она проще в обслуживании и тестировании кода, б) во многих школах она преподается как "правильный" способ, и в) программисты - это те люди, которые нравится создавать модели вещей. oop хорошо вписывается в этот "модельный" менталитет. представьте "вещь", используя один кусок кода, затем пусть ваши "вещи" взаимодействуют с другими "вещами", такими как соединение частей lego. аккуратный, чистый, аккуратный. :)</p><p>правда в том, что с такими вещами, как кеширование кода операции, автозагрузка практически не дает никаких преимуществ в скорости, только организационные. и не поймите меня неправильно, выгода - это выгода, а хорошая организация - это хорошо. но вы получаете лучшую организацию через организацию вещей, а не через автоматизированные процессы.</p><p>можете ли вы написать код, чтобы переместить весь код в классы, а затем сделать функции простыми хуками в эти классы? конечно, наверное. что это поможет? ничего существенного.</p><p>чтобы удовлетворить ваши конкретные желания:</p><blockquote> <p>гораздо сложнее обесценивать функции. поэтому этот вопрос начинается с начала переписывания системы.</p> </blockquote><p>во-первых, я думаю, что вы имели в виду "не одобряйте".</p><p>во-вторых, вы не можете переписать все целиком и достичь своих целей. в этом вся моя суть. вернитесь и посмотрите на 3.1 или 3.2. теперь посмотрим на 4.0. обратите внимание на количество классов и то, как они действительно подвергаются рефакторингу с течением времени.</p><p>нет смысла тратить кучу времени на переписывание рабочего кода только для того, чтобы получить те же результаты, если только вы не собираетесь реально улучшить его в процессе. поскольку каждая часть в wordpress улучшается, она обычно превращается в систему класса/ооп. постепенная эволюция. изменяйте со временем, чтобы позволить старым плагинам исчезнуть и создать новый код для его поддержки и исправления и тому подобное. вы не можете разрушить мир в одночасье и ожидать, что все последуют за вами, вы должны изменить вещи медленно и методично.</p>

<p>@xeoncross,</p><p>вы пишете в своем профиле wp dev</p><blockquote> <p>вы можете заметить, что некоторые из моих вопросов уходят вглубь некоторых проблем, потому что я стремлюсь к максимально возможной оптимизации в моих приложениях.</p> </blockquote><p>это все хорошо для приложения, вашего приложения или приложения, над которым вы работаете; или ваша собственная философия и методы программирования.</p><p>но wordpress - это сообщество, и как таковое работает по-другому. он может пожертвовать (из-за отсутствия лучшего слова) вещами с точки зрения структур программирования, языков и эффективности, которые являются приоритетами для небольших или индивидуальных проектов.</p><p>но wordpress выигрывает в результате существования сообщества. экосистема велика и разнообразна, развитие развивается, и в результате - или, несмотря на это, wordpress очень популярен.</p><p>как сообщество, wordpress не может действовать так же, как отдельный проект или разработчик.</p><p>вы сравниваете яблоки и апельсины, а также деревья, на которых они растут, и людей, которые любят яблоки лучше, чем апельсины.</p><p><em> я не считаю себя программистом, и я не могу спорить о преимуществах и преимуществах ооп, классов, процедур и так далее. </em></p>