好吧，我知道我可以用什么样的工具进行优化，分析等等......所以现在我知道我所有的瓶颈。但我不能无限地优化它们。我的意思是说 ？例如，我有A作为我的主要瓶颈，我应用优化，之后CPU时间，记忆时间等变小，但与整个项目相关仍然是瓶颈。我的意思是，每次在任何项目中都有瓶颈，那么在我应该停止优化的最后一点是什么？
答案 0 :(得分：2)
如果你的代码的某一部分导致瓶颈，也许最好的办法就是退一步看看整个画面，我的意思是你的整体设计。有时，摆脱 无法修复 瓶颈的最佳方法是重新考虑您的设计模式。
以下是一些很好的消息来源
答案 1 :(得分：1)
在我看来，这取决于要求。如果用户正在等待几秒钟来加载页面，那就没关系。但如果用户在聊天时等待几秒钟，则需要进行优化。当我登录谷歌时，它需要超过5秒（它很长），但之后它很快。但如果聊天时需要相同，那么我会更喜欢其他一些电子邮件ID。通常，在mysql，Web服务，循环等中需要优化。当在Google图像中搜索时有大量图像时，需要时间。用户可以等待它。转到页面，看看你的自己，你在加载页面时的感受。它是长吗？如果是，那么你需要优化。
答案 2 :(得分：1)
假设您找到了一个“瓶颈”，当您修复它时，可以节省30％的时间。 例如时间从10秒降到7秒。
然后假设您找到另一个，当您修复它时，可以节省30％的7s或2.1s。 这将时间降至4.9秒。
注意几件事。
第二个问题只是原来10个问题的21％，所以原来这是一个不太大的问题，但在解决了第一个问题之后，第二个问题变得更大，为百分之一。
将其视为加速比率。解决第一个问题给你的加速比为10/7或1.43x。修复第二个给你的比例为7 / 4.9或1.43x。总加速比为10/7乘以7 / 4.9，等于10 / 4.9或2.04x。你的程序速度提高了一倍以上。
这两个问题占原来10个问题的30％和21％。如果还有两个，占14.7％和10.3％，他们在个人资料中看起来很小。但如果你修复了所有这四个，那么你的程序速度将翻两番！如果你错过了其中任何一个，你就不会。
这是怎么回事。直到你真正达到最低点，你总能让程序变得更快，而后来看起来微不足道的问题变得有价值。 你得到的最终加速比可能让你感到惊讶。
并非所有的探查者都能找到所有问题。 如果其中一个问题是您的探查器找不到的问题， 你会发现你认为你已经尽可能优化的一点，但你没有。
如果您想要超越这一点，您需要一种能够找到每个问题的分析技术。 Here's how I do it.