当前位置: 首页>>WEB开发>>正文


get_option()vs get_theme_mod():为什么一个慢?

问题描述

我已经在我的各种项目中使用get_theme_mod()一段时间了。我决定利用WordPress v3.4中的主题自定义API一旦可用,因为我觉得它是我的客户使用的不可或缺的工具。

过了一段时间,我开始注意到我的网站感觉比平时稍微迟钝,而且定制器特别需要很长时间才能加载。在调查期间通过大量的反复试验,我决定在将我的设置(即$wp_customize->add_setting())从theme_mod注册到option时尝试切换type

一旦我这样做并将我的所有get_theme_mod()调用换成get_option(),我注意到使用后一种设置的速度非常显著增加,而不是前者在前端,特别是在后端的定制器中。我一直在浏览WordPress核心,试图找出解决这个原因的答案,但似乎无法分辨出这种情况下特定的挂断是什么。

社区可能对get_option()执行速度明显快于get_theme_mod()的任何见解将不胜感激。

最佳解决办法

答案是肯定的,theme_mod功能会慢一些,但不是很明显,而且好处大于差异。

主题mod存储为选项。因此,从本质上讲,theme_mod函数是选项函数的包装器。

首先,要了解theme_mod设置作为数组存储在单个选项中,并键入特定主题名称。所以,如果我这样做:

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

然后我在数据库中实际获得的是一个名为theme_mods_themename的单选项行,其中包含一个序列化数组(‘aaa’ => 123,’bbb’ => 456)。

现在,get_theme_mod将会变慢,因为它实际上正在进行两次get_option调用。首先,它获得主题的名称。然后,它获得theme_mods_themename选项。所以那里有50%的速度损失。完成的其余工作主要在于过滤器,因为有一个额外的过滤器调用,但除非你在过滤器上有东西,这是有点无关紧要的。

请注意,选项系统将检索到的数据存储在对象缓存中,因此它不会在此处进行多个数据库调用。只有第一次使用才会导致数据库命中。

set_theme_mod会稍慢一些,因为它会进行相同的两个get选项调用,然后再次调用get_option获取主题名称,然后它会使用现在更改的全部选项进行update_option。这会导致数据库更新,并且它发送更多数据的事实确实可能导致明显的减速。更新几个字节比更新更大的行更快。但通常不是你注意到的那么多。除非你有很多设置……

主题mod函数可能总体上是优化的,当然,但你仍然应该使用它们而不是get_option,因为这是因为子主题。

直接使用选项行的问题是您直接使用它们并使用特定的键名称进行设置。

如果我有一个名为”AAA”的主题,并且我在其他网站上创建了一个名为”BBB”的子主题,那么我的”AAA”主题可能会使用名为”example”的选项。当我更新一个站点并更新我的选项时,相同的选项现在将应用于我的子主题。如果我不想这样做怎么办?如果我希望子主题使用不同的选项设置,该怎么办?

主题模型,通过包含实际主题名称(而不是硬编码值)作为键的一部分,确保站点上的每个”theme”使用其自己的一组设置。我可以来回切换,设置不会在它们之间传输,它们保持我设置的方式。更简单,更明显,更直观。

如果某些未来的核心更改或插件修改了theme_mods的工作方式,那么您将自动获得其中的好处而无需任何更改。包装总是会变慢,这是不可避免的,它是包装纸的本质。然而,你仍在编写PHP代码,而不是机器语言。我们使用这样的包装器来简化事物并分离功能。主题不应该知道或关心他们的选项如何存储在数据库中,或者命名如何工作。 theme_mod功能提供更简洁的解决方案,更清洁。

次佳解决办法

get_theme_mod只是get_option的包装。理论上,因为它是另一层抽象,它的工作速度较慢,但​​在实践中差异不应大到足以让人注意到。

如果您在theme_mod挂钩上挂了一些慢速代码,则可能会导致实际的速度差异。

参考资料

本文由朵颐IT整理自网络, 文章地址: https://duoyit.com/article/2468.html,转载请务必附带本地址声明。