LiquidBounce ScriptAPI 简易基准性能测试
-
作者: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 / GraalVM 21
- Minecraft:Fabric 1.21.4 + Sodium 0.6.6(LiquidBounce 当前不兼容 Lithium)
测试结果
Legacy
测试项目 斐波那契数 埃氏质数筛 世界扫描 标准脚本 149ms 61482ms 1539ms 混合脚本 59ms 1147ms 311ms Nextgen
测试项目 斐波那契数 埃氏质数筛 世界扫描 标准脚本 + ZuluJDK 9890ms 9629ms 9368ms 标准脚本 + GraalVM 144ms 1277ms 1952ms 混合脚本 + ZuluJDK 67ms 1023ms 195ms 混合脚本 + GraalVM 52ms 982ms 177ms 结论
虽然有一些特殊版本的 LiquidBounce 我并未测试,但大多数都是过时版本,参考价值有限(例如 Legacy-b73 1.12.2 或 Nextgen 0.17,后者尚未支持 GraalJS JIT)。
对于 Legacy 版本,自 b57 以来一直使用 Nashorn 作为脚本引擎,理论上每个版本的性能差异不大。
对于 Nextgen 版本,如果没有使用 GraalVM 启动 LiquidBounce,在运行标准脚本时可能会出现卡顿现象。推荐使用 LiquidLauncher 来解决这个问题。