【问题标题】:Micro-optimisation of keys versus in_array() in PHPPHP 中键与 in_array() 的微优化
【发布时间】:2011-07-31 16:18:55
【问题描述】:

因此,您可以选择构建一个数组,因为您知道在代码的后面几行您将需要检查该数组中是否存在值。在我看来,您至少有两种选择:

$values_array = array(
    'my_val',
    'my_val2',
    'and_so_on',
);

if(in_array('my_val', $values_array)) {
    var_dump('Its there!');
}

或者您可以使用关联数组并使用键来包含您的值:

$values_array = array(
    'my_val'    => '',
    'my_val2'   => '',
    'and_so_on' => '',
);

if(isset($values_array['my_val'])) {
    var_dump('Its there!');
}

您会选择哪种方法,为什么?您的目标仅仅是减少处理时间还是尽量减少使用的内存量?

也许你不会使用我的两种微不足道的方法,而有另一种很棒的方法来解决这个简单的问题。

这是一个没有考虑实际应用的理论问题,但数组中可能有数千个选项。看看每个人都认为哪种方法更好,这确实是一个推测性的问题。无论是出于可读性、速度还是内存使用原因考虑。

【问题讨论】:

  • 如果您使用地图(如第二个示例中所示),请考虑使用 array_key_exists 而不是 isset - 否则会为您尝试访问的每个不存在的键抛出 E_NOTICE。
  • @Piskvor 是的,但许多人已经对这两者进行了基准测试,发现isset() 更快。例如:cybersprocket.com/2010/programming-languages/… 更有趣的是stackoverflow.com/questions/700227/…
  • @Treffynnon:如果您担心issetarray_key_exists 的性能,那么您就是在进行过早的优化。这可能很有趣,但如果你一直在它上面花费大量时间,这表明存在问题(更不用说性能问题可能在编译的内置函数之外的其他地方)。
  • @Piskvor +1 进行过早优化,并指出代码中的其他地方更容易炸鱼或低垂的果实更有可能影响最终结果。
  • @Piskvor isset 没有给我未定义键的错误。我做错了什么?

标签: php optimization micro-optimization


【解决方案1】:

真的吗?使用更适合您和您的应用程序需求的变体。尤其是元素这么少,远远超出了衡量的范围。

但两者之间存在真正的语义差异。第一个定义一个列表,第二个定义一个映射。如果$array 应该代表一个列表,请使用第一个,如果它应该代表一个地图,请使用第二个(很明显,是吗?;))。

完全:让永远不要这样的微观优化方法影响您的应用程序设计。

【讨论】:

  • 这是一个理论问题,没有考虑到实际应用,但数组中可能有数千个选项。看看每个人都认为哪种方法更好,这确实是一个推测性的问题。无论是出于可读性、速度还是内存使用原因考虑。
  • 同意让它影响应用程序设计不是一个好主意。我只是好奇地想看看人们的反应。
【解决方案2】:

代码可读性和可维护性总是胜过优化。

为了节省几微秒而刻意弄乱代码,开发人员浪费的时间通常超过了节省的微秒的价值。

如果您正在编写执行速度确实足以影响此类事情的东西,那么 PHP(或实际上任何解释语言)可能是错误的语言。如果您正在尝试优化 PHP 代码,几乎可以肯定有比这更好的起点。

【讨论】:

  • 我倾向于同意并经常批评我团队中来自 Ruby (RoR) 的开发人员牺牲了可读性!
【解决方案3】:

嗯,我倾向于第二个,因为我有一种 感觉 认为这个更理想。而且我经常使用它。
但是,如果它成为瓶颈,我会衡量替代方案。

无论如何,当我的数组相对较小(最多数百个项目)时,我永远不会想到这些东西。 无论如何,我会尽量避免在繁重的数组上进行此类搜索。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-05-14
    • 2017-02-14
    • 2011-03-30
    • 2019-05-03
    • 1970-01-01
    • 2014-01-30
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多