从 OptaPlanner 8.22.1 升级到 Timefold 1.1.0 或 OptaPlanner 8.37.0 后性能下降

问题描述 投票：0回答：2

我有一个基于 OptaPlanner 8.22.1.Final 的课程安排应用程序。

升级到Timefold 1.1.0后，性能测试用例的执行时间增加了约100%。除了指向 Timefold 库的更改之外，应用程序代码是相同的。 JDK 从 11 上升到 17。

以下是有关测试的一些详细信息。

测试用例1

之前

2023-09-10 13:02:17,390 INFO Solving started: time spent (5), best score (-730init/0hard/0medium/0soft), environment mode (REPRODUCIBLE), move thread count (4), random (JDK with seed 0).
2023-09-10 13:02:17,902 INFO Construction Heuristic phase (0) ended: time spent (517), best score (-40hard/-2265medium/0soft), score calculation speed (32158/sec), step total (365).
2023-09-10 13:03:31,283 INFO Local Search phase (1) ended: time spent (73898), best score (0hard/0medium/0soft), score calculation speed (24932/sec), step total (28873).
2023-09-10 13:03:31,283 INFO Solving ended: time spent (73898), best score (0hard/0medium/0soft), score calculation speed (24979/sec), phase total (2), environment mode (REPRODUCIBLE), move thread count (4).

之后

2023-09-10 15:38:24,216 INFO Solving started: time spent (11), best score (-730init/0hard/0medium/0soft), environment mode (REPRODUCIBLE), move thread count (4), random (JDK with seed 0).
2023-09-10 15:38:24,590 INFO Construction Heuristic phase (0) ended: time spent (385), best score (-40hard/-2265medium/0soft), score calculation speed (87852/sec), step total (365).
2023-09-10 15:42:03,882 INFO Local Search phase (1) ended: time spent (219677), best score (0hard/-10medium/0soft), score calculation speed (35648/sec), step total (31041).
2023-09-10 15:42:03,883 INFO Solving ended: time spent (219677), best score (0hard/-10medium/0soft), score calculation speed (35734/sec), phase total (2), environment mode (REPRODUCIBLE), move thread count (4).

测试用例2：

之前

2023-09-10 13:03:32,508 INFO Solving started: time spent (16), best score (-3796init/0hard/0medium/0soft), environment mode (REPRODUCIBLE), move thread count (4), random (JDK with seed 13).
2023-09-10 13:03:34,728 INFO Construction Heuristic phase (0) ended: time spent (2236), best score (-10hard/-6460medium/0soft), score calculation speed (40084/sec), step total (1898).
2023-09-10 13:08:37,166 INFO Local Search phase (1) ended: time spent (304674), best score (0hard/0medium/0soft), score calculation speed (13550/sec), step total (83120).
2023-09-10 13:08:37,167 INFO Solving ended: time spent (304675), best score (0hard/0medium/0soft), score calculation speed (13742/sec), phase total (2), environment mode (REPRODUCIBLE), move thread count (4).

之后

2023-09-10 15:42:04,616 INFO Solving started: time spent (32), best score (-3796init/0hard/0medium/0soft), environment mode (REPRODUCIBLE), move thread count (4), random (JDK with seed 13).
2023-09-10 15:42:07,385 INFO Construction Heuristic phase (0) ended: time spent (2801), best score (-10hard/-6460medium/0soft), score calculation speed (64265/sec), step total (1898).
2023-09-10 15:52:28,340 INFO Local Search phase (1) ended: time spent (623756), best score (0hard/0medium/0soft), score calculation speed (12726/sec), step total (82742).
2023-09-10 15:52:28,341 INFO Solving ended: time spent (623757), best score (0hard/0medium/0soft), score calculation speed (12954/sec), phase total (2), environment mode (REPRODUCIBLE), move thread count (4).

在引入 Bavet 后，我还尝试了 OptaPlanner 8.37.0.Final 和其他几个版本。它们都会导致性能下降。

我需要进行哪些更改才能使应用程序运行得更快？我预计应用程序运行速度会稍快一些。

performance optaplanner timefold
2个回答
0
投票

从测试日志来看，在我看来，您正在将苹果与橙子进行比较。具体来说：

测试用例1：

  • “之前”跑了约 1 分 15 秒
  • “之后”跑了约 3 分 30 秒。
  • “之后”的结果比“之前”明显快。 (~+45%)

测试用例2：

  • “之前”跑了约 5 分钟。
  • “之后”跑了约 10 分钟。
  • “之后”的结果仅差了约 6%，这可以通过一次运行到另一次运行之间 JVM 性能的自然差异来轻松解释。

考虑到输入条件（特别是解决时间或目标分数）不一样，并且这不是一个科学基准，我会谨慎地从中得出任何结论。

以下是一些提高基准可靠性的指南：

  • 设置共享终止条件。如果您要衡量性能，基于时间的终止并不理想。也许是基于分数或基于步数的终止。
  • 多次运行每个实验，取结果的平均值。每次迭代 10 次就足够了。
  • 尝试消除变量。如果您说您已经使用 OptaPlanner 8 重现了这一点，请不要对 Timefold 进行基准测试（还）。相反，尝试在不切换到 JDK 17 的情况下重现它。这样，我们就会知道它是否与 JDK 相关。

最后一点，这并不是我第一次听说 OptaPlanner 8.22 之后一段时间发生了“某些事情”，导致它在某些情况下运行速度明显变慢。不幸的是，目前还没有人提供可以显示减速情况的代码。你可以成为第一个。

0
投票
过度拟合

并且JDK版本的变化暴露了这一点。如果这是真的，则 OptaPlanner/Timefold 版本升级不相关。 同一 JDK 版本的基准测试应该（反）证明这一点。

动机

测试用例根据日志使用不同的随机种子：

测试用例 1（之前+之后）：
    Solving started: ... random (... seed 0)
  • 测试用例2（之前+之后）：
    • Solving started: ... random (... seed 13)
  • 

    • 这很不寻常。这是“过度拟合”的迹象。过度拟合在测试期间会产生更好的结果，但在生产中会产生相同或更差的结果。
我怀疑 optaplanner-benchmarker 已被（错误）用来为每个数据集找到“最佳”随机种子。这使得它容易受到随机实现中任何变化的影响。


JDK 17 更改了随机实现。

    




    

    


  

  

    
最新问题


  





  

    © www.soinside.com 2019 - 2025. All rights reserved.