Жесткое кодирование и производительность WordPress
На странице Оптимизация/производительность WordPress предлагается жестко кодировать статические переменные, а не ссылаться на них с помощью функций WordPress. Я думаю, что понимаю причину этого.
Но как насчет того, чтобы сделать что-то вроде следующего:
function foobar() {
global $post;
$post_ID = $post->ID;
$site_url = site_url();
// Use $post_ID and $site_url multiple times throughout the function
}
Является ли это лучшей производительностью, чем явный вызов $post->ID и site_url() каждый раз, когда вы хотите ссылаться на них? Или это не имеет значения?
4 answers
Это вопрос PHP, никак не связанный с WP, но поскольку он был поддержан....
TL;Версии Dr - Компиляторы делают такого рода микрооптимизацию намного лучше, чем вы, нет смысла даже пытаться.
Давайте посмотрим, что компиляторы будут делать с вашим кодом вопроса
// is this less efficient
$meta = get_post_meta($post->ID,'meta');
$permalink = get_permalink($post->ID);
//then this?
$post_ID = $post->ID;
$meta = get_post_meta($post_ID,'meta');
$permalink = get_permalink($post_ID);
В первом разделе компилятор может видеть, что вы используете $post->ID дважды, не внося никаких изменений в объект $post, и он вычислит значение только один раз и будет использовать его в обоих звонки.
Второй раздел в основном делает то, что компилятор сделал бы сам по себе, но, поскольку в нем больше текста, вы анализируете медленнее, и поэтому общее время выполнения больше
Но как насчет
foo1(site_url());
foo2();
foo3(site_url());
// vs
$site_url = site_url();
foo1($site_url);
foo2();
foo3($site_url);
Здесь компилятор не может предположить, что результат site_url() будет одинаковым при каждом использовании, поэтому оптимизация не может быть выполнена, и вторая версия, вероятно, будет быстрее.
НО..... что, если в будущем вы решите, что вызов foo3 не необходимо, и вы удаляете эту строку? мы снова возвращаемся к ситуации, когда ваш код делает именно то, что компилятор будет делать сам, но замедляет синтаксический анализ
И вы действительно можете быть уверены, что foo2() не будет изменен в будущем, чтобы сделать что-то, что изменит результат site_url()? с оптимизированным кодом это создаст ошибку.
Это преждевременные/ранние оптимизации, и вам следует избегать необходимости их выполнять, поскольку они обычно оказывают очень незначительное влияние на производительность сайта.
Рекомендации в связанном кодексе являются BS. Я не буду вдаваться в то, как использование опций в wordpress оптимизируется самим ядром, поэтому в этой статье утверждается, что
$a = 5;
Быстрее, чем
$a = foo();
function foo() {
return 5;
}
Это верно, но разница обычно не стоит того, чтобы навсегда потерять возможность манипулировать этими значениями с помощью плагинов и возможность управлять этими значениями от администратора.
Страница, на которую вы ссылаетесь, предлагает жестко кодировать значения, которые в противном случае могут привести к запросу базы данных. Что-то вроде URL-адреса сайта - это опция, которая загружается автоматически и кэшируется, дополнительные вызовы не приводят к дополнительным запросам к базе данных. Я скажу, что оба приведенных вами примера будут иметь значение, достаточно близкое к нулю, чтобы об этом даже не стоило беспокоиться.
Существует компромисс между оптимизацией процессора и памяти. Если вы храните значения в переменных, а не вызываете функцию и получаете значения во время выполнения, это, безусловно, оптимизирует производительность процессора, но будет потреблять больше системной памяти.
Как уже объяснял Винод Далви, сохранение переменных вместо того, чтобы вычислять их снова и снова, сэкономит процессор, но потребит больше системной памяти. Вам нужно будет найти хорошее сочетание использования процессора и памяти. Эта комбинация может отличаться на разных серверах, поэтому трудно дать хорошее представление о том, сколько вы должны хранить и сколько вы должны рассчитать.
Если вы действительно хотите сделать свои коды как можно быстрее, вам следует проанализировать свои сценарии на эффективность. Это может должно быть сделано, как показано в этом вопросе о стековом потоке. Лучше всего, если вы проанализируете свои сценарии, измените некоторые переменные, проанализируете их снова и так далее. Это должно быть сделано на разных серверах, чтобы получить хорошее представление о том, как далеко вы должны зайти в хранении и вычислениях.