Performance 编程语言的性能多久会成为一个重要问题？

似乎我经常听到人们批评某些编程语言，因为它们“性能差”，或者因为其他一些语言通常“更快”（不一定适用于特定的应用程序）。然而，我的经验和教育告诉我，无论何时，只要出现绩效问题，至少可能会发生以下情况之一：

瓶颈不在于CPU，而在于其他设备，如网络或硬盘

性能差是由您的算法造成的，而不是由您使用的语言造成的

我的总体印象是，编程语言本身的速度在绝大多数情况下几乎是无关紧要的，严重的数据处理问题除外。即使在这些情况下，我相信您也可以使用混合方法，只对CPU密集的部分使用较低级别的语言，这样您就不会完全失去更抽象语言的好处

你同意吗？编程语言速度在大多数情况下是无关紧要的，还是批评家有权指出语言性能问题

---

我希望这个问题不要太主观，但在我看来，应该有一个相对客观的答案。

这不可能回答得这么宽泛。这就像在问大发动机在汽车中是否是一种浪费。对一些人来说，是的。对其他人来说，一点也不。介于两者之间

有无数的因素在起作用。您的目标环境是什么？最终用户部署还是服务器？假设我们正在讨论服务器的web开发和编码。众所周知，RoR（相对）缓慢。相比之下，NET是相当快的。但是RoR也有.NET无法与之竞争的RAD特性

• 昨天启动并运行你的应用程序比可伸缩性更重要吗
• 你的商业模式是生存还是消亡取决于你服务页面的毫秒数，还是你进入市场的时间
• 您的TCO和应用程序体系结构是否支持向外扩展或向上扩展？你甚至认为需要扩大规模吗

这些只是架构师在做出平台/语言决策时必须回答的一小部分问题。速度重要吗？有时候。如果我计划编写一个最终需要扩展到每秒数千个事务的LoB服务，并将其部署到企业环境中，我可能会选择.NET。如果我有一个像销售这样的Web2.0业务的想法，我需要在昨天利用这个想法，我知道我可能不会因为有足够的业务而在准备之前关闭网站

---

老实说，这过于简化了一个非常复杂的问题，但希望能说明这一点：不可能简单地“说”它是否重要。

性能可能是库、操作系统等中的一个严重问题。然而，我相信90%以上的时间里，原始性能是不相关的

在许多情况下，更重要的是时机。任何垃圾收集语言在这方面都会有一些不可预测性，这使得它们不适合嵌入式和实时设计空间

GC'd语言和“slow”语言的重叠是相当大的，因此当真正的问题是时间不一致时，您可能会看到一种语言由于速度原因而被打折

有一些分配/线程等方案允许垃圾收集，同时也保证系统部分的运行时，例如，尽管我个人没有在任何地方看到它的使用

---

简短回答：大多数时候，语言的速度是不相关的（在合理的范围内），语言的选择是基于熟悉程度和可用的库。

令人惊讶的是，一个系统的性能是编程语言、它所执行的系统、，系统正在执行的操作及其依赖的外部资源（网络、磁盘、慢行打印机等）

如果你的系统很慢，不要猜测，测试它

---

如果计算中有任何“规则”，那就是“测试你的假设”。其他一切都是粗略的指南。

我认为这是一个好问题。要回答这个问题，需要有一个考虑性能的通用框架，所以让我试着提供一个。（有些听起来很明显，但请耐心听我说。）

为了简单起见， 让我们来考虑一个简单的应用程序，它有一个特定的工作要做，然后启动，然后完成，而你关心的是挂钟时间。让我们假设一个标准的CPU周期率和一个单处理器

持续时间由时间片流组成（比如纳秒）。要完成这项工作，需要的时间最少，而且通常大于零。没有所需的最长时间。如果一个程序花费的时间超过了最小纳秒数，那么严格地说，其中一些纳秒的花费是不必要的（即，由于糟糕的原因）

因此，为了优化程序的执行时间，有必要找出它所花费的不必花费的纳秒（即没有充分理由的纳秒）并将其删除

一种方法是，如果可能的话，一步一步地完成程序，并在每一步跟踪它为什么要执行该步骤。如果原因不好，则有机会删除步骤

另一种方法是从程序执行中随机选择纳秒，并询问其原因。例如，程序计数器可以告诉您程序正在做什么，但调用堆栈可以告诉您原因。为了让纳秒有一个好的理由，调用堆栈上的每个调用指令都必须有一个好的理由。如果调用堆栈上的任何指令没有很好的理由，那么就有机会进行优化。事实上