开发者不再关心性能了吗？我对此感到非常怀疑，至少绝大多数的开发者（90%以上）仍然关心性能。

几周以前，我在这里的论坛上就性能展开了一个有趣的讨论。我比较了一些简单Perl代码和对应C#代码的文本处理速度。由于我很可能考虑了磁盘限制而不是其它问题，所得到的数字（Perl快大约25%或更多）并不是决定性的。

经过一些调整，我对测试进行微调，仅仅测定处理速度，输入存储在内存中的数据，而不把磁盘速度考虑在内，完成基本的性能评估。整件事情让我印象最深刻的是，自我和另一位开发者谈论代码性能以来，已经过去相当长一段时间。当然，谈到编码时，一个明智的开发者可能会打出“啊哈，但那是如此地慢！”这张王牌，但我们很少平淡地谈及性能。

这个周末，我变得对ASP.Net应用程序对象和它的运行机制极其好奇。深入研究以后，我最终阅读了大量关于ASP.NET提供的缓存选项方面的材料。我知道存在有这个缓存对象，但我从未真正研究过它，认为它相当平常，和大多数内置ASP.Net一样。

但我错了！虽然这个系统能够实现巨大的性能改善，但令人震惊的是，我从未听说有人使用它、说明如何使用它、甚至是提到过它。它甚至支持SQL Server通知缓存一个数据源发生变化，缓存应该作废的功能；它还提供一个复查机制，以便你能够在需要时触发重新缓存。相当不错的功能！

这引出了以下问题：为什么好像没有人关心呢？

好，我们暂时坦率来讲。我在这里将会谈论到ASP.Net，它作为一个非常快速的系统并不为人所知。.NET相当接近于本地代码，在许多程序中，与C#相比，可能要快10%-20%（根据你执行的工作而定）。在现代硬件上，对多数应用程序而言，这几乎不算什么。

确实，五或十年前因为“缓慢”而被放弃的解释语言（Perl、Python和PHP）与今天的托管代码系统（.Net和J2EE）相比速度相当快。

但在一个Web服务器环境，或任何类型的服务器环境中，速度降低10%-20%等同于硬件需求增加10%-20%（由于每台服务器在操作系统上损失了一些资源，如果使用群集，在所需的管理成本上还要损失更多，所以实际的增加要比10%-20%稍多一些），这意味着电费账单要增加10%-20%，IT支持时间（特别是在部署方面）延长15%-25%左右。

对大型应用程序（特别是使用大型应用程序的SaaS/ASP提供商）来说，这等同于数百万美元。但今天的许多公司选择增加成本而非开发者的时间。毕竟，在任何现代框架中进行开发仍然要快于编写C++代码。

即便如此，马虎编码或不利用缓存这样的内置加速器无异于往窗户外扔钱。性能非常像多线程——没有必须遵守的规则，但存在大量确定的指导方针，以及许多权衡和让步。除非程序员知道他或她在做什么，他们使情况恶化的风险非常高。

坚持遵守缓存范例，一名糟糕的开发者可能缓存太多内容，增加管理费用，使得非缓存性能也受到不利影响。或者，一名糟糕的开发者可能缓存错误内容，在需要实时结果的时候交付过时的结果。此外，一名糟糕的开发者甚至可能缓存需要不断更新或不应缓存的数据，这负面地增加了管理费用；等等。

事情与进行缓存与否无关。我真正感到奇怪的是：为什么这么多开发者似乎并不关心缺乏提高性能技巧的问题。而且更奇怪的是，为什么统计员也不关心呢？统计员是每一位开发才的致命伤。他们是那些告诉我们不要使用保护眼睛的工作岗位照明，而要使用挂在头顶的便宜日光灯的人；是他们让我们使用25美元的椅子、5美元的键盘、7美元的鼠标和100美元的显示器。

而且，他们应用零压力将服务器房的实际运作成本降低10%、15%或更多。我发现这是一种古怪的态度。就算这样，许多性能重构时间几乎和初次编写代码的时间一样长，仅仅补充了边际改进的不足。确实，开发者的时间非常宝贵。当然，用一个小时重构代码就表示这一个小时不能产生利润。

时间和价值之间的权衡称之为ROI。你可以投入多少时间来改善性能在很大程度上取决于项目的规模。编写出知道会运行缓慢的代码——如不提前计算循环的结束条件，强迫在每次循环过程中重新进行计算——没有借口可言。优秀的开发者会编写出迅速运行的代码；其它条件，如外部缓存库、多线程等可以稍后再添加。

但拙劣的开发者开始就编写出马虎、缓慢的代码，然后找出“给它增加硬件”的借口，或责备语言/系统管理员/网络工程师/框架开发者/最新的操作系统补丁/等等因素。因此，请努力成为一名优秀的开发者。培养一些健康的习惯，帮助你提高代码运行速度，减少调整需要，并了解你的选项，从而提高性能。在竞争激烈的开发领域，拥有这种编程知识和方法的开发者会在人群中脱颖而出。

来源： http://blogs.techrepublic.com.com/programming-and-development/?p=436