我是一名PHP开发者，我一直认为微小的优化不值得花时间去做。如果你真的需要额外的性能，你要么编写更高效的软件架构，要么编写一个C++扩展程序来处理耗时任务（或者最好使用HipHop编译代码）。然而，今天我的一位同事告诉我，在字符串连接时使用单引号和双引号有很大的区别。
is_array($array)
和
$array === (array) $array
我当时觉得“嗯，这真的是一个毫无意义的比较”，但他不同意我的看法..而他是我们公司最优秀的开发人员之一，并负责一个每天执行约5000万个SQL查询的网站。因此，我在想：他可能错了吗？微观优化真的值得花时间去做吗？
$array === (array) $array 比 is_array($array) 快得多。快了7倍以上。但每次调用只需要大约 1.0 x 10 ^ -6 秒（0.000001秒）。所以，除非你要调用它成千上万次，否则不值得这样做。如果你确实需要调用成千上万次，那么我建议你重新考虑你的代码逻辑...$array === (array) $array 需要复制一个新变量，并且需要在内部迭代比较数组，所以对于大型数组来说，它会慢得多。例如，在一个包含100个整数元素的数组中，is_array($array) 和小型数组的误差范围相同（< 2%），在10000次迭代中运行时间为 0.0909 秒。但是，$array = (array) $array 的速度非常慢。对于只有100个元素的数组，它已经比 is_array() 慢了两倍以上（运行时间为 0.203 秒）。对于1000个元素，is_array 的运行时间保持不变，但转换比较的时间增加到 2.0699 秒...is_array()有函数调用的开销，而强制转换操作是一种简单的语言结构...在C代码中迭代小变量通常比函数调用开销更小。但是，对于较大的变量，差异会增加...is_array()。它的source code基本上显示它是一个O(1)操作。这意味着它是一个恒定时间操作。但我们还需要看看函数调用。在PHP中，具有单个数组参数的函数调用可以是O(1)或O(n)，具体取决于是否需要触发写时复制。如果在$array是变量引用时调用is_array($array)，将触发写时复制并执行变量的完整拷贝。is_array()是最佳情况下的O(1)和最坏情况下的O(n)。但只要不使用引用，它始终是O(1)...(array)强制转换运算符会导致对数组进行O(n)迭代以进行转换（通过copy_ctor调用）。O(1)的，但对于对象来说是O(n)的。is_identical_function() 的代理。现在，如果 $array 不是数组，is_identical 将短路。因此，它的最佳情况为 O(1)。但是，如果 $array 是一个数组，它可以再次短路，如果哈希表相同（意味着两个变量都是彼此的写入副本）。因此，该情况也是 O(1)。但请记住，我们在上面强制进行了复制，所以如果它是一个数组，我们不能这样做。因此，由于zend_hash_compare，它是O(n)...
因此，最坏情况下运行时间的结果如下表：
+----------+-------+-----------+-----------+---------------+
| | array | array+ref | non-array | non-array+ref |
+----------+-------+-----------+-----------+---------------+
| is_array | O(1) | O(n) | O(1) | O(n) |
+----------+-------+-----------+-----------+---------------+
| (array) | O(n) | O(n) | O(n) | O(n) |
+----------+-------+-----------+-----------+---------------+
memcmp()或类似函数）。所以n=5对于is_array产生11个操作，而对于===(array)产生22个操作...
现在，is_array()确实有一个栈推入的O(1)开销（由于函数调用），但这仅在极小的n值下占主导地位（我们在上面的基准测试中看到，仅10个数组元素就足以完全消除所有差异）。
我建议选择可读性更好的方法。我认为is_array($array)比$array === (array) $array更易读。所以你可以兼得两种方法的优点。
我用于基准测试的脚本：
$elements = 1000;
$iterations = 10000;
$array = array();
for ($i = 0; $i < $elements; $i++) $array[] = $i;
$s = microtime(true);
for ($i = 0; $i < $iterations; $i++) is_array($array);
$e = microtime(true);
echo "is_array completed in " . ($e - $s) ." Seconds\n";
$s = microtime(true);
for ($i = 0; $i < $iterations; $i++) $array === (array) $array;
$e = microtime(true);
echo "Cast completed in " . ($e - $s) ." Seconds\n";
编辑：记录一下，这些结果是在Linux上使用5.3.2得出的...
编辑2：修复了数组速度较慢的原因（由于迭代比较而不是内存原因）。请参见compare_function中的迭代代码...
当你有证据表明你正在优化一个瓶颈时，微优化是值得的。
通常情况下，它并不值得——尽可能编写最易读的代码，并使用真实的基准测试来检查性能。当你发现自己遇到了瓶颈时，只需微调那部分代码（同时进行测量）。有时微小的优化可以带来巨大的改善。
但是不要对所有代码进行微优化……这将使维护变得更加困难，并且很可能会发现你忽略了真正的瓶颈，或者你的微小优化反而损害了性能，而不是帮助它们。
gprof及其现代版本。完成任务后，他们就会继续下一个话题。那么学生们该怎么办呢？在课堂上，他们敞开心扉，希望被智慧充实。然而毕业后，他们却认为角色发生了反转——他们的工作是教育我们这些老古董他们所学到的东西。我相信你也见过这种情况。 :-) - Mike Dunlaveyis_array($array)是首选方法，而$array === (array) $array则是所谓的更快的方法（这也带来了一个问题，为什么不使用该比较实现is_array，但我偏离了主题）。* 好吧，实际上我确实会，但这更多是因为我有轻微的强迫症，而不是好的开发实践。
is_array()）。 - Michael Burr微观优化不值得。代码可读性比微观优化更重要。
关于无用的微观优化的文章 by Fabien Potencier（Symfony 框架的创造者）很棒:
print 和 echo，哪个更快？
Print 使用了一个额外的操作码因为它实际上返回了一些东西。我们可以得出结论，echo 比 print 更快。但是一个操作码几乎什么都不花费。即使脚本有数百次调用 print。我已经在全新的 WordPress 安装中尝试过了。这个脚本在我的笔记本电脑上在结束之前停止并显示“总线错误”，但操作码的数量已经达到了 230 多万。足以说明问题。
嗯，有比速度更重要的事情需要考虑。当你看到“更快”的替代方法时，你是立刻想到“哦，这是在检查变量是否是数组”，还是想着“…什么鬼”？
因为实际上，考虑使用这种方法时，它被调用的频率有多高？确切的速度优势是什么？当数组较大或较小时，是否有效？不能在没有基准测试的情况下进行优化。
此外，如果优化降低了代码的可读性，则不应该进行优化。事实上，减少几十万次查询（这通常比人们想象的要容易得多）或者在适用的情况下对其进行优化，对性能会更加有益，而不是进行微小的优化。
另外，不要被那个经验丰富的人吓倒，正如其他人所说，要自己思考。
所以，如果你想编写具有竞争力的软件，今天很大程度上会涉及多线程、SIMD、GPU、GPGPU、通过改进内存访问模式（循环瓦片、SoA、热/冷字段拆分等）提高参考局部性，甚至在极端情况下优化分支预测等方面，而不是算法突破，除非你正在攻克极少有程序员探索过的领域。
有时仍会出现潜在改变游戏规则的算法突破，例如最近的体素锥追踪。但这些是例外，那些想出这些方法的人通常会投入他们的生命到研究和开发中（他们通常不是编写和维护大型代码库的人），并且它仍然归结为微优化是否可以将体素锥追踪应用于实时环境，如游戏等。如果您不擅长微优化，则即使使用这些算法突破，也无法获得足够的帧速率。