循环累计时间对比PHP函数效率有多大意义？

最近看了不少唯代码效率论者在选择同类功能函数时的纠结，看了一些他们比对XX函数和YY函数效率的代码，这些函数的单独执行时间大都是 0.x毫秒 甚至 0.0x毫秒 计算的，而且一般无一例外的比对方法都是循环个一万次，10万次之类的，看累积的时间差距来比较效率。
        诚然，相对而言，这些函数本身的确有效率高下之分，但是这个循环累积的比对方式有多大意义呢？一个函数万次的累加也就百十毫秒，况且这些函数在实际应用中几乎不大可能出现这种万次以上的循环操作，就算是同时并发，那也是一万个并发的排队时间也仅仅是百十毫秒吧，这个时间对于用户而言几乎没有任何感觉，况且一个能同时并发上万的网站早该做负载平衡了吧？
        当然如果是本身执行时间就比较长的函数的确需要选择效率高一些的，但像一般的执行时间零点几毫秒计的函数就没必要死抠那一点点可怜到忽略不计的效率了，诚然知道函数效率也是有帮助的，但也不能陷入代码效率的泥淖，应该在效率无关痛痒的时候尽可能选择一些简单易用的函数来完成功能，而不是为了效率而效率，你觉得呢？

LZ淡定吧，总有些蛋疼的人，没能力在算法和架构上下功夫，跑去挖函数的效率，实在让人无语。
     你挖就挖吧，关键是还挖的那么不专业。考虑到热启动的了没？考虑到疲劳了没？10次，1万次，100万次，二者效率差是否都一样？如果不一样，那为什么不一样？考虑到测试时覆盖的面全了没？有结合OPCODE，源代码分析效率的差异了没？就那么循环10万次，往那一丢，就认定某个函数就是快啊。在程序中就执行一次的函数还斤斤计较。你要说挖个内核效率还有话说，就一脚本的函数还挖来挖去。。。
       大可一笑置之。

能提高效率就提高呗，但也不要太钻牛角尖。如果是框架就要计较了，因为你的框架里的东西是“底层”，调用频率很高，次数多了就见到效果了。你可以看一篇文章《一个Sqrt函数引发的血案》

    文章好像也是老古董了，所涉及的问题也是在古董时代的效率优化，因为当时的硬件速度相对于现在来说慢很多，所以现在看来很多效率差距不大的函数，按当时的硬件标准来说很可能会差距比较大，挖潜增效就会成为当时的必然选择，但现在来说硬件的提升已使我们无法感受到软件效率上的差异了，尽管这个差异真实存在着。

这篇文章起码挖的有深度，还是值得一看

作为一个程序员要追求极致，即使无法达到2楼的境界，也要在力所能及的范围内达到最好。
最终的结果也许并不重要，重要的是过程。