在 Optaplanner 中分析约束流分数计算

Posted 2023-03-06

【中文标题】在 Optaplanner 中分析约束流分数计算

【英文标题】：Profiling constraint streams score calculation in Optaplanner

【发布时间】：2021-06-01 11:46:47

【问题描述】：

我正在分析我的 Optaplanner 项目中的分数计算，以了解是否有任何热点可以从优化中受益。但是，visualvm 显示大部分时间都花在了org.drools.modelcompiler.constraints.ConstraintEvaluator$InnerEvaluator$_2.evaluate 的自我时间中。因此，我假设这种方法实际上是运行大量约束代码的方法。找出哪些特定代码段花费最多时间的最佳方法是什么？

【参考方案1】：

要了解约束流的一点是，它不是命令式编程，因此传统的性能优化技术（如代码分析）不会很有帮助。相反，我建议您将约束流视为 SQL - 拥有快速 SQL 的方法是考虑您的数据如何流动、您如何加入以及索引的内容。

最近我写了一篇博文，解释了making CS run fast 背后的技巧。但是，CS 是由 Drools 引擎在内部解释的，因此研究它可能也会给你some insights。并非所有见解都适用于 CS，但如果您查看 drools-metric，您应该能够看到哪些约束相对较慢。然后它变成了一个调整游戏。

【讨论】：

Haskell 非常适合代码分析，但它绝对不是必须的。我理解您的信息，即代码分析对约束流不是很有用，但我不会为此责怪功能范式。

你是对的。我在某种程度上说错了——我的观点是，在调试规则引擎时，代码中没有一个点可以让探查器帮助您。相反，您需要分析引擎如何处理数据，而您的性能改进将来自于此。

博文和链接文档中的见解非常有帮助。好答案。 +1

drools-metric 告诉我 JoinNode(36) 非常慢。您能否阐明我应该如何将其映射到我的代码？文档中提到了 ReteDumper，但我不确定如何将 ReteDumper 与约束流一起使用？

在不了解您的限制条件的情况下，这很难说。这将是 join() 语句之一。 drools-metric 通常不也输出规则的名称吗？它应该与相关约束的名称相匹配。如果不在那里，我唯一能想到的就是将约束一个一个消除，并以这种方式找出有问题的约束。据我所知，没有任何钩子可以让您将 ReteDumper 与 CS 一起使用 - 但听起来我们最终可以添加一个合理的东西。