性能管理通常被视为一种巫术，因为性能问题通常在应用程序开发完成之后才会出现。到那时，就难以确定它们的根源。然而，一旦十分准确地确定了性能问题的起因，那么修正它常常是比较简单的事情。工程师在寻找更有效的方法来执行特殊任务方面通常具有相当的创造性（有时他们的创造性过了头）。对于任何给定的性能问题，通过使用高速缓存来减少冗余计算或者只是添加更多的硬件，解决方案可能会与用更有效的算法进行替换一样简单。但是，要清楚地确定性能问题的根源会很困难，而设计复杂程序甚至 更加困难，所以首先要使它们没有性能问题。

　　虽然编程决策 ― 如算法或数据表示的次优（sub-optimal）选择，无法重用先前计算的结果，或者糟糕的资源管理 ― 通常被认为是性能问题的直接起因，但大多数性能问题还有一个更深的起因：无法首先将性能管理、目标和测量集成到开发过程中。

　　问题？什么问题？

　　您如何知道何时有性能问题呢？对于大多数开发团队，回答（用美国高级法院法官 Potter Stewart 对罪行描述的话来讲）是：在遇到时才知道。这是问题的核心 ― 性能目标、度量和测量常常没被考虑到，直到发现时，已经太晚了。

　　最常见的性能管理策略是……也没什么，它通常采用下列两种形式之一：

　　在应用程序开发完成之前完全忽略性能

　　开发时进行优化，这通常意味着只关注极微小的性能考虑事项，而忽略较大的方面

　　这两种策略共有同一个基本问题 ― 它们没有将性能管理视作开发过程的一个集成部分。

　　有缺陷的性能策略 A：完全忽略性能

　　第一种方法是完全忽略性能，该方法将性能视作可以在项目结束时处理的事情，比如象编写发行说明或构建安装程序。该策略基本上靠运气，因为计算机运算速度一年比一年快，所以在性能方面总能够应付得过去。