嗯，我知道我可以使用什么样的工具来优化、分析等......所以现在我知道我所有的瓶颈。但我不能无限优化它们。我的意思是？例如，我将点 A 作为我的主要瓶颈，我应用了优化，之后 CPU 时间、内存时间等变得更小，但与整个项目相关，它仍然是瓶颈。我的意思是，在任何项目中，每次都会出现瓶颈，那么我应该停止优化的最终点在哪里？
如果你的代码的某个部分造成了瓶颈，也许最好的办法是退后一步，看看整个画面，我的意思是你的整体设计。有时，摆脱无法修复的瓶颈的最佳方法是重新思考您的设计模式。
这里有一些很好的来源
- http://en.wikipedia.org/wiki/Software_design_pattern
- http://www.phptechi.com/php-design-patterns.html
假设你发现一个"瓶颈"，当你修复它时，可以节省30%的时间。例如，时间从 10 秒下降到 7 秒。
然后假设你找到另一个，当你修复它时，可以节省 30% 的 7 秒，即 2.1 秒。这使时间降低到4.9秒。
请注意几件事。
- 第二个问题
只有原来的 10 秒的 21%，所以最初它是一个不太大的问题，但在解决第一个问题后，第二个问题变得更大了，作为一个百分比。
将其视为加速比。修复第一个问题为您提供了 10/7 或 1.43 倍的加速比。修复第二个给你的比率是 7/4.9 或 1.43 倍。总加速比为 10/7 乘以 7/4.9，等于 10/4.9 或 2.04 倍。您将程序的速度提高了一倍以上。
这两个问题占了原来10年代的30%和21%。如果再有两个，占14.7%和10.3%，它们在轮廓中看起来会很小。但是，如果您修复所有四个问题，则程序的速度将翻两番！如果你错过了其中任何一个，你就不会错过。
事情就是这样。在你真正跌入谷底之前，你总是可以使程序更快，而那些起初看起来微不足道的问题后来变得值得。您获得的最终加速比会让您大吃一惊。
并非所有探查器都能找到所有问题。如果其中一个问题是探查器找不到的问题，你会到达一个你认为你已经尽可能地优化的地步，但你没有。
如果你想超越这一点，你需要一种能够找到每个问题的分析技术。这是我的做法。
在我看来，这取决于要求。如果用户等待几秒钟加载页面，没关系。但是，如果用户在聊天时等待几秒钟，则需要优化。当我登录谷歌时，它需要超过 5 秒（它很长），但之后它很快。但是，如果在聊天时需要相同的时间，那么我更喜欢其他电子邮件ID。通常，在mysql，Web服务，循环等中需要优化。当有很多图像时，例如在谷歌图片上搜索时，这需要时间。用户可以等待它。转到页面，看看你自己，你在加载页面时的感受。长吗？如果是，则需要优化。