上述观点的论调听上去像认为优化和速度根本不重要。但是事实是，许多时候运行时效率至关重要。一个例子是，你的网络应用有一个特定的端点需要相当长的时间来响应请求。同时你知道它需要有多快，也知道它要被优化到什么程度。
在这个例子中，发生了下面两件事：
我们关注到某个运行慢的端点。
我们认为它慢，因为我们了解什么是足够快，并且它没能达到这个指标。
我们不必在应用中对每个服务进行细节调优。每个服务只需要能“足够快”来满足用户的需求就够了。用户会发现某个端点花费了几秒时间返回，但是他们并不会注意到你把一个 35 毫秒的请求优化到了 25 毫秒。你只需要达到“足够好”就可以了。免责声明：不得不说一些应用，如实时拍卖应用，确实需要细节调优，能提升一毫秒算一毫秒。但是这是一个特例，而不是业界的规则。
为了弄清如何优化某个端点，第一步你需要对你的代码进行性能分析，并尝试整理出其中的瓶颈。归根到底：
任何不考虑瓶颈的调优都是幻想。—— Gene Kim
如果你的优化并不解决瓶颈，那你就是在浪费你的时间，而且还不能解决真正地问题。不解决瓶颈，你就不会在性能上得到显著的提升。如果你尝试着在了解瓶颈前优化，你就像在和你的代码在玩打地鼠的游戏。在排查和确定瓶颈前优化代码也是“不成熟优化”的表现。Donald Knuth 常被引用下面的观点，虽然他本人称这也是从其他人那儿听来的：
不成熟的优化是万恶之源。
Donald Knuth 在一次关于维护代码库的讨论中进行了下面的完整描述：
我们应该忘记那些小的性能提升，这占了 97% 的时间：不成熟的优化是万恶之源。但同时我们也不能放过那至关重要的 3%。
换句话来说，大部分时间，你不应该关心代码的优化。它们通常已经足够好了。如果没有能达到标准，我们应该只需要改变那 3% 的代码。你并不会因为你的代码使用一个 if 替代了一个方法，得到几毫秒的性能提升而获得任何奖励。只有在分析之后再进行优化。