get_option () vs get_theme_mod (): Pourquoi est-ce plus lent?

14

J'utilise get_theme_mod() depuis un certain temps dans divers de mes projets. J'ai décidé de tirer parti de l'API Thème Personnalisation dans WordPress v3.4 une fois qu'elle était disponible, car je pensais que c'était un outil indispensable à mes clients.

Après un certain temps, j'ai commencé à remarquer que mes sites se sentaient un peu plus lents que d'habitude, et le Customizer, en particulier, a mis beaucoup de temps à se charger. Après de nombreuses tentatives d’essais et d’erreur au cours de mon enquête, j’ai décidé de remplacer le type lors de l’enregistrement de mes paramètres ( $wp_customize->add_setting() ) de theme_mod à option .

Une fois que j’ai fait cela et échangé tous mes get_theme_mod() appels vers get_option() , j’ai remarqué une augmentation très significative de la vitesse en utilisant la dernière configuration par rapport à la précédente et en particulier dans le Customizer sur le backend. Je me suis penché sur le cœur de WordPress pour tenter de comprendre pourquoi, mais je n'arrive pas à discerner quelle est la situation particulière de ce scénario.

Toutes les informations que la communauté pourrait avoir sur get_option() performant nettement plus rapidement que get_theme_mod() seraient grandement appréciées.

    
posée ntg2 18.07.2014 - 22:06

4 réponses

18

La réponse est oui, les fonctions theme_mod seront plus lentes, mais pas de manière significative, et les avantages l'emporteront sur les différences.

Les mods de thème sont stockés en tant qu'options. Ainsi, les fonctions theme_mod sont essentiellement des enveloppes autour des fonctions options.

Tout d’abord, comprenez que les paramètres theme_mod sont stockés sous forme de tableau dans une seule option, associée au nom de thème spécifique. Donc, si je fais ceci:

set_theme_mod('aaa',123);
set_theme_mod('bbb',456);

Ensuite, la base de données contient une seule ligne d’options portant le nom theme_mods_themename, qui contient un tableau sérialisé contenant ('aaa' = 123, 'bbb' = 456).

Maintenant, get_theme_mod sera plus lent car il effectue en réalité deux appels get_option . Tout d'abord, il obtient le nom du thème. Ensuite, il obtient l'option theme_mods_themename . Voilà donc une perte de vitesse de 50%. Le reste du travail consiste principalement en filtres, dans la mesure où il existe un appel de filtre supplémentaire, mais à moins que ce filtre ne comporte quelque chose, il est un peu insignifiant.

Notez que le système d'options stocke les données extraites dans le cache d'objets. Par conséquent, il ne fait pas plusieurs appels à la base de données ici. Seule la première utilisation aboutit à un hit de base de données.

Le set_theme_mod sera un peu plus lent car il lance ces deux mêmes appels d'options, puis il appelle un autre get_option pour récupérer le nom du thème, puis il effectue update_option avec le jeu complet qui a maintenant changé options. Cela provoque une mise à jour de la base de données et le fait qu’elle envoie beaucoup plus de données peut en effet être à l’origine d’un ralentissement notable. La mise à jour de quelques octets est plus rapide que la mise à jour d'une ligne plus grande. Mais pas autant que vous remarquerez, généralement. Sauf si vous avez énormément de réglages ...

Les fonctions de mod de thème sont probablement dues à une optimisation globale, certes, mais vous devriez quand même les utiliser à la place de get_option et autres parce que des thèmes enfants.

Le problème avec l’utilisation directe des lignes d’options est que vous les utilisez directement et que vous utilisez des noms de clé spécifiques pour vos paramètres.

Si j’ai un thème appelé "AAA" et que j’en crée un thème enfant appelé "BBB" à utiliser sur un autre site, mon thème "AAA" peut utiliser une option nommée "exemple". Lorsque je mets à jour un site et que mon option est mise à jour, la même option s’applique désormais à mon thème enfant. Et si je ne voulais pas le faire? Et si je voulais que le thème enfant utilise un ensemble différent de paramètres d'option?

Les mods de thème, en incluant le nom du thème (et non une valeur codée en dur) dans la clé, garantissent que chaque "thème" du site utilise son propre ensemble de paramètres. Je peux basculer et les paramètres ne sont pas transférés entre eux, ils restent comme je les ai configurés. Plus simple, plus évident, plus intuitif.

Et si un changement principal ou un plugin futur modifie le fonctionnement de theme_mods, vous en profiterez automatiquement, sans aucun changement. Les emballages seront toujours plus lents, c'est inévitable, c'est la nature des emballages. Néanmoins, vous écrivez toujours du code PHP, pas du langage machine. Nous utilisons des wrappers comme celui-ci pour simplifier les choses et séparer les fonctionnalités. Les thèmes ne devraient pas avoir besoin de savoir ou de se préoccuper de la façon dont leurs options sont stockées dans la base de données ou de la façon dont la dénomination fonctionne. Les fonctions theme_mod fournissent une solution plus simple, plus propre.

    
réponse donnée Otto 21.09.2014 - 19:19
3

get_theme_mod est juste un wrapper autour de get_option . En théorie, parce que c’est une autre couche d’abstraction, cela fonctionnera plus lentement, mais en pratique, la différence ne devrait pas être assez grande pour être remarquée par un humain.

Des différences de vitesse réelles peuvent survenir si du code lent est accroché aux hooks theme_mod.

    
réponse donnée Mark Kaplun 20.07.2014 - 05:11
0

Peut-il y avoir quelque chose dans Customizer alors? Je vois la même chose que l'OP ici.

Je peux confirmer qu'avec environ 30 options, le temps de chargement du Customizer est passé d'environ 3 s à environ 0,5 lors du passage à get_option sur get_theme_mod

.

En appelant directement les méthodes, je vois une différence de 2ms.

( enlace )

Il se peut que vous ne remarquiez pas lorsque vous comparez directement les API, mais il doit y avoir un problème avec la façon dont elles sont utilisées dans Customizer.

    
réponse donnée VykRevler 21.07.2014 - 23:55
0

Vous pouvez TESTER L'HEURE de get_option (100 itérations) à l'aide de ce code (indiqué dans functions.php ou ailleurs):

add_action('wp','My_Test');
function My_Test(){
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_option('blogdescription'); }
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_theme_mod('blogdescription'); }
    var_dump(microtime(true));
    exit;
}   




Une autre pensée

Je ne sais pas, si cela fait une différence (peut-être que les développeurs de Wordpress le savent mieux), mais je pensais que si un site Web génère un trafic ÉLEVÉ et que chaque page est chargée, il doit disposer de centaines d'options. Je vais rejoindre beaucoup d'options dans un get_option ? comme ceci:

update_option('my_extra_optss',  array(
      'myNAME' => 'George',
      'myAGE'  => 43 ));

alors:

$x = get_option('my_extra_optss');
$x['myNAME'];
$x['myAGE'];
................

Cela rendra-t-il un peu plus rapide le site?

    
réponse donnée T.Todua 11.07.2015 - 12:14

Lire d'autres questions sur les étiquettes