LiquidBounce ScriptAPI 简易基准性能测试

[CookieChinese]

作者：mumy

前言

LiquidBounce自从b57时把ScriptAPI的语言更换到JavaScript后提供了强大的扩展性，但社区中并未对其性能进行过较为具体的评估。
最近我才意识到了这个情况，所以我打算尝试做个简易的Benchmark以评估其性能。

测试

我计划将脚本分为两类：标准脚本和混合脚本（例如 mumyPacketDebugger）。
测试将包括斐波那契数、埃氏质数筛选和世界（方块）扫描。
对于 Nextgen 版本，我分别使用 ZuluJDK 与 GraalVM 进行测试。

最终结果将取决于运行时间稳定后的最短耗时。

脚本

legacy b99 和 nextgen 0.24 的 Benchmark.zip

测试平台

• 操作系统：Windows 10 22H2
• CPU：Intel i9-14900HX（锁频 5.0GHz）
• 内存：DDR5 16GB + 16GB 5600MHz

测试环境

• Legacy
  • 版本：b99
  • JDK：ZuluJDK 8
  • Minecraft：Forge 1.8.9 + OptiFine M5
• Nextgen
  • 版本：0.24
  • JDK：ZuluJDK 21 / Oracle GraalVM 21
  • Minecraft：Fabric 1.21.4 + Sodium 0.6.6

测试结果

Legacy

测试项目	斐波那契数	埃氏质数筛	世界扫描
标准脚本	149ms	61482ms	1539ms
混合脚本	59ms	1147ms	311ms

Nextgen

测试项目	斐波那契数	埃氏质数筛	世界扫描
标准脚本 + ZuluJDK	9890ms	9629ms	9368ms
标准脚本 + Oracle GraalVM	144ms	1277ms	1952ms
混合脚本 + ZuluJDK	67ms	1023ms	195ms
混合脚本 + Oracle GraalVM	52ms	982ms	177ms

结论

虽然有一些特殊版本的 LiquidBounce 我并未测试，但大多数都是过时版本，参考价值有限（例如 Legacy-b73 1.12.2 或 Nextgen 0.17，后者尚未支持 GraalJS JIT）。

对于 Legacy 版本，自 b57 以来一直使用 Nashorn 作为脚本引擎，理论上每个版本的性能差异不大。

对于 Nextgen 版本，如果没有使用 GraalVM 启动 LiquidBounce，在运行标准脚本时可能会出现卡顿现象。推荐使用 LiquidLauncher 来解决这个问题。