Asp.net 性能与代码质量

你认为为了代码质量和可维护性而牺牲一些性能值得吗？我记得杰夫·阿特伍德（Jeff Atwood）的一篇帖子说，硬件便宜，开发人员不便宜。我想我想把它改成“硬件便宜，时间不便宜。”

我注意到，最近我在做一个MVC项目，有时候我为了挤出一点额外的性能而浪费了几天的时间，我开始觉得这不值得。我刚刚发现自己在设计ASP.NET MVC应用程序时遇到了麻烦。我非常喜欢IQueryable，因为它允许我附加到查询中，这样我就可以得到一些流畅的代码来使用它。但是，能够这样做似乎增加了控制器/BLL的更多责任

---

那你觉得呢？在web应用程序的情况下，您是否愿意为了可维护/更干净的代码而牺牲一些性能？你认为过早地尝试优化你所能做到的一切是对的吗？因为正如我们所见，您无法预测所有需求。

我真的不相信这是一个非此即彼的选择。如果您编写了干净、简单的代码，并且只执行了正确的处理次数，那么您将拥有一些性能最好的代码。其实很简单。

显而易见的答案是这要看情况。如果你的应用程序速度慢到足以显著影响可用性，并且你有测量数据证明你的优化确实有帮助，那么牺牲可维护性可能是一个合理的权衡。另一方面，如果你还没有测量，或者应用程序的速度不够慢，不足以影响可用性，那么一定要追求可读性、可维护性和灵活性。这可以归结为过早的优化是万恶之源

注意：如果你知道性能对你的应用程序很重要，那么设计时算法和架构优化并不一定是坏的，但就你的问题而言，你显然是在谈论上面提到的微型优化

此外，在您的具体情况下，如果您无法判断您的应用程序是否足够慢，从而影响可用性，那么这还为时过早。如果你能，那就不是了

让它工作

如果性能有问题，请分析并确定问题

解决问题

如有必要，重复步骤1-4

利润

---

在服务器端，我绝对重视自己的时间而不是应用程序性能。如果我注意到我的站点在数据库请求等方面的性能不够好，升级服务器硬件是一种替代解决方案，它可以（至少短期内）解决我的问题，而无需查看代码

但是，如果应用程序的网络效率非常低，我会花相当多的时间来改进这一部分。发送大量数据会影响我的用户，无论我如何使用自己的服务器和上行线路——如果他们不喜欢性能，他们就不会回来

---

但正如其他一些人所说，这不是一个非此即彼的问题-这在很大程度上取决于情况，性能问题有多严重，在应用程序中的哪个位置等等。

质量（易于阅读）和性能都不是最重要的-正确性才是最重要的

托尼·霍尔爵士有句名言：“我们应该忘记小效率，比如说97%的时间：过早优化是万恶之源。”

报价的第一部分几乎被遗忘了（它不那么容易说出），因此许多没有经验的工程师在软件项目的设计阶段没有考虑性能。这几乎总是一个致命的错误，因为后来由于基本的设计缺陷，设计糟糕的应用程序很难优化。同时，在性能瓶颈还不清楚的情况下，尝试使用巧妙的技巧来节省CPU周期是没有意义的

至于您的问题，我认为一个设计合理、能够满足其特定性能要求的应用程序不需要以不可维护或“不干净”的方式进行编码。只有当发现这些性能瓶颈时（例如，你发现你的应用程序在10%的代码中花费了90%的时间），你可能需要谨慎地考虑使用少量代码中的优化技巧，从而使其保持可维护性和易于理解。

---

许多Web应用程序的优点在于，使用各种缓存技术可以极大地提高性能。当你控制服务器环境（就像你说的，硬件很便宜）时，你可以确保你缓存掉你的Web应用程序中那些常用的部分。如果您使用抽象层，这并不会导致代码无法维护。Facebook是Web应用程序的一个很好的例子，它以利用缓存（memcached）而闻名。

在一定程度上同意这一点。开发人员的时间是昂贵的，而分析和优化代码是一种非常昂贵的方法，可能无法获得太多的性能增益。话虽如此，这取决于应用程序的类型和工作环境

如果您正在开发一个web应用程序，那么您可以通过修复一些简单的问题（主要是在客户端）来进行大规模改进。比如通过连接CSS/JS文件来减少HTTP请求，构建图像精灵等等。。。与实际分析代码相比，这将给您带来巨大的收益，并且非常好地利用了开发人员的时间

我不知道我是否同意“硬件比开发者便宜”的说法。当然，硬件可以帮助您扩展应用程序并使其具有更高的性能，但您最不想做的事情就是依赖强大的硬件。如果您的软件与硬件的耦合过于紧密，则在迁移到新数据中心、升级服务器等方面会失去很多灵活性。。。没有