智能优化算法优化svm代码_优化代码时做出正确的决定

智能优化算法优化svm代码

您手头有一项优化任务。 太好了–您终于有可能做一些有趣的事情，而不用执行另一个发票处理屏幕。
优化任务（希望）与某些非功能性需求相关联，例如应用程序每秒必须处理的事务数或允许的每个事务的最大时间。

现在，您已经确定了应用程序中导致性能问题的部分。 您的应用程序的这一部分使用特定的算法。 您正在考虑将解决方案切换到另一种实现方式，并希望评估性能影响。 正如我们在前一篇文章中所讨论的那样 ，您明智地选择了每秒的用户事务数作为度量标准。 您可以使用旧的实现来运行压力测试，写下每秒实现的操作数，然后使用新的实现来运行相同的压力测试，写下每秒的新操作数。

接下来，您比较数字并做出一些决定。 这些决策中的一些可能包括对进一步的性能测量和/或新实现的优化的要求。 让我提出一些非常简单的示例：

• 使用旧算法，需要1,000笔交易，耗时100秒
• 使用改进的算法，相同的1,000个事务耗时90秒

大！ 新版本更快！ 您对该算法所做的更改使您的性能提高了10％。 现在，您可能需要在优化算法的基础上，根据有关后续步骤的信息做出进一步的决策。 但是，让我们考虑更多的信息：花费在垃圾收集上的时间。 您可以从GC日志中提取总的GC暂停时间。 那是您的应用程序停止进行世界范围内的GC工作的时间。 然后我们可以得到以下图片：

• 使用旧算法，需要1,000笔事务处理100秒，其中GC暂停使用了20秒
• 使用改进的算法，1,000个事务花费了90秒，而GC暂停花费了27秒

我们可以从这些信息中得出什么？ 首先，算法的运行时间从100 – 20 = 80秒减少到90 – 27 = 63秒，加快了21％。 其次，GC占用您大约30％的CPU时间。 基于此，您的进一步算法的优化计划不仅应着眼于运行速度，还应着重于减少内存使用量和GC时间。

您应该如何决定选择哪个方向？ 为了回答这个问题，我们应该调查您的性能要求。 也许您已经满足了您每秒需要处理多少个事务的要求。 但是所有交易都在短时间内处理完了吗？ 也许您最初只测量每秒交易数的明智想法可能不是最好的？

这些技术要求可以转化为两个不同的方面，即吞吐量和延迟。 您当前的工作已经提高了吞吐量，但是可能会引入更多和/或更长时间的GC暂停，从而延迟了延迟。

NFR将指导您算法的进一步优化。 假设您仍未达到吞吐量要求。 您接下来的步骤是什么？

考虑到您的实现在GC暂停上花费了30％的时间 ，仅这个事实就应该引起危险。 在典型情况下（是的，我知道这就像测量医院的平均温度并据此做出决定一样）， GC暂停时间不应超过总时间的5％ 。 而且，如果您超过10％，则极有可能您应该对此采取某些措施。

减少GC暂停的第一步是调查JVM配置。 也许您只需要增加最大堆大小(-Xmx)? 也许您应该调整世代大小（ -XX:NewRatio ， -XX:SurvivorRatio …）？ 也许您应该尝试使用其他垃圾收集器（ -XX:+UseConcMarkSweepGC ， -XX:+UseParallelGC …）？ 取决于您的应用程序，正确的答案可能是更改上述内容的组合，或者对其中某些内容进行更改，或者根本不提供任何帮助。

当配置JVM不能提供足够的结果时，下一步就是调查您的数据结构。 也许您可以通过更改源代码来减少GC暂停。 也许您可以摆脱基元周围的所有包装器类，并显着减少开销？ 也许您可以看看所使用的Collection类并减少造成的开销？ 还是对于某些特殊情况，当您的算法不断地创建和销毁相同的对象时，也许对象池可能是一个好主意？

并且在上述情况下，仅在此之后，您才可能真正想开始减少算法本身带来的开销。 在某些特殊情况下，这可能会导致您发现划分速度太慢。 而且，您需要找到一种巧妙的方法，用数据结构支持的更便宜的操作来替换它。 否则，每次写入java.util.concurrent.atomic.AtomicBoolean所伴随的内存障碍都太昂贵了。 但是，让我们将这些情况留给另一个故事，当我描述我一生中处理过的一些最奇怪的CPU浪费时。

结论–如果您要优化代码，请确保已对吞吐量和延迟的要求进行了仔细考虑。 而且您将不会仅坚持一种优化技术。 希望阅读本文后，您现在可以在自己的武器库中使用更多工具。

参考： Plumbr Blog博客上的JCG合作伙伴 Nikita Salnikov Tarnovski 优化代码时做出正确的决定 。

翻译自: https://www.javacodegeeks.com/2012/12/making-the-right-decisions-when-optimizing-code.html

智能优化算法优化svm代码