我正在使用getrusage()测试所有这些不同的结构来计算执行它们之前和之后(ru_utime + ru_stime)的变化。
事实证明，对类似的构造执行相同的任务并没有太大区别。以下是结果： 比print快 foreach printf （1.5 ± 0.5）% 比
for循环（迭代 1kk if/else while±for元素的索引数组）快 （1.5 0.5）% 比switch快 （±
6.0 ± 1.0）%（在两个案例中测试， 6例，10例可能）。
所以我想知道，这些差异真的重要吗？如果我们在代码中使用所有最有效的此类结构，它会有所作为吗？也许那里有 6%、8%，那里有 9% 或 10%，总结起来会改变我们代码的效率吗？
或者这些差异仍然不明显，我的意思是服务器对请求的响应几乎不会变化？另外，如果我们使用 if/else 超过 switch 、for 超过 while、printf 超过 print 、foreach 超过 for ，它会占用更多的内存吗？
在性能方面使用StackOverflow答案回答您的问题：
对于if/else与switch：相同的性能（更多）。
对于for vs foreach vs while ：没关系（更多）。
对于printf vs print ：一个不比另一个好（更多）。
我的拙见是，你使用任何看起来更舒服和/或更好地满足你需求的东西（彼此之间有细微的差异，除了性能之外，这取决于你需要什么）。在性能方面，为了最大限度地提高性能，您还应该注意其他事项，例如降低程序中使用的代码的O复杂性、网络延迟处理、需要时任务的并行化等。你的问题有点笼统，所以我试图以同样的方式回答。
- 你是对的。百分之几并不重要。
- 操作的可伸缩性对应用程序性能的影响比这百分之几要大得多。从这个意义上说，可扩展性意味着如果您接收的数据量增加 2 倍、10 倍，您的系统将如何运行。您的系统是否会仅减慢 2 倍、10 倍（如果是线性）或 4 倍、100 倍（二次）等 http://en.wikipedia.org/wiki/Scalability
- 此问题通常发生在数据库端，如其他所述。有"大"操作。有些数据可能很大。
- 大多数开发人员不必太关心资源。是的。性能分析是处理性能问题的正确方法。
OP 写道：
这些差异真的重要吗？如果我们在代码中使用所有最有效的此类结构，它会有所作为吗？
嗯，是也不是。 您是否正在编写超低延迟应用程序？ 硬（确定性）实时应用程序？ 如果是，那么是的。 等待用户的键盘输入？您的CPU不会因无聊而死亡，这是一个奇迹。 所以，没有。
9%的差异可能可以忽略不计（你的精灵领主不会杀死巨魔），或者可能非常显着（你祖母的生命支持系统杀死了她）。
基本上，这不是一个可以在这里回答的问题。 撇开环境/执行/编译器优化问题不谈：它不仅是一个书本长度的主题，而且具体的书将取决于你在谈论什么样的程序，以及性能包络的后果和要求是什么。 我猜想，对于99.99%的程序员来说，switch或if/else语句或类似的窥视孔优化之间的差异（实际上）绝对为零。
古老的格言"让它可读，让它运行，然后让它运行得更快，如果你必须的话"可能是你最好的行动方案。 即使在这种极其罕见的情况下，它也可能很重要，只需确保使用探查器来确定"使其快速运行"阶段的"位置"部分真正需要的位置。