Sepals

Sepals

一款极其激进且实验性的 Minecraft 服务器性能优化模组。

我们建议将 Sepals 与 Lithium 和 Async 搭配使用，以获得最佳性能。

前言

首先，

Sepals 是一系列高度实验性的服务器端优化集合，专门针对 Minecraft 中 AI、实体处理和任务系统等非常具体的性能瓶颈。与 Lithium 提供广泛的“通用”优化不同，Sepals 专注于对少数极其耗时的原版机制进行深度重写——特别是村民大脑、青蛙行为、实体挤压、目标筛选和附近实体感知。

那么它实际上做了什么？

如果你运行大型农场、村民大厅、密集的怪物围栏，

或任何在小区域内存在数百/数千个实体的场景，

Sepals 通过避免原版最昂贵的 AI 操作，显著降低了游戏刻耗时。

如果你运行的是带有小型农场的普通 SMP 服务器，你可能不会注意到太大区别。

它是实验性的，并非每一项优化都保证与原版行为完全一致，

但在性能压力测试中，收益可能是巨大的。

兼容性

目前，Sepals 与几乎所有模组兼容。

以下是经过验证的模组列表及其与最新 Sepals 版本的要求：

如果你不知道选择哪个版本，请使用优化模组的最新版本，因为 Sepals 会确保与它们的兼容性。

重要提示

Sepals 不支持任何旧版本和快照版本的 Minecraft；所有错误修复和功能仅在新版本中提供。

当与 Async 一起使用时，

请手动比较使用 Sepals 和 Async 的性能，并编辑它们的配置，以找出哪些优化是值得的，

因为每台机器的结果都不同。

Sepals 相关功能：``enableSepalsEntitiesCramming``。

配置

性能

测试在飞喵提供的 Mars 服务器上进行，CPU：Intel i7-14700K；游戏内存：4G；操作系统：Ubuntu 24.04.1 LTS；

Minecraft 版本：1.21。

实体挤压

使用盒子缓存来防止过多的 'getOtherEntities' 调用

-- 注意 --
此功能会忽略每个实体的记分板/队伍谓词，
并可能导致意外行为。

此问题不会影响原版中的任何内容，除非使用命令方块。

-- 状态 --
默认启用

1390 个村民挤压在 7x7 空间内：

加权随机

使用二分搜索替换原版加权随机

-- 警告 --
此功能可能不值得启用，
因为 Spark 证明在构建范围表时它比原版更慢，
即使二分搜索耗时接近 0 ms。

-- 状态 --
默认禁用

-- 警告 --
未经测试。

偏向长跳任务

使用 Sepals 的长跳任务实现替换原版

如上所述，二分搜索几乎没有成本
sepals 实现将在生成目标的同时构建范围表
并使用 Catheter 替换 Java 流

同时，重新安排青蛙大脑中应该跳跃的条件，以获得良好的性能

-- 注意 --
此功能无法在游戏运行时更改
需要重启服务器才能应用更改

-- 状态 --
默认启用

800 只青蛙挤压在 7x7 空间内：

| 原版

(LongJumpTask) | 43.1 ms | 100 % |

| Lithium

(LongJumpTask) | 7.5 ms | 17 % |

| Sepals

(SepalsLongJumpTask) | 0.2 ms | 0.4 % |

| Sepals + Lithium

(SepalsLongJumpTask) | 0.05 ms | 0.1 % |

| 原版

(LongJumpTask) | 43.1 ms | 100 % | 100 % |

| Lithium

(LongJumpTask) | 3.6 ms | 9 % | 48 % |

| Sepals

(SepalsLongJumpTask) | N/A ms | 0 % | 0 % |

| Sepals + Lithium

(SepalsLongJumpTask) | N/A ms | 0 % | 0 % |

NearestLivingEntitiesSensor 中的快速排序

使用 FastUtil 的快速排序替换 Java TIM 的排序

-- 状态 --
默认启用

800 只青蛙挤压在 7x7 空间内：

青蛙可攻击目标筛选器

重新安排可攻击条件
将成本最低的条件放在前面，
从而降低计算高成本条件的概率

-- 抱怨 --
Mojang 的可攻击谓词是：

!entity.getBrain().hasMemoryModule(MemoryModuleType.HAS_HUNTING_COOLDOWN)
 && Sensor.testAttackableTargetPredicate(entity, target)
 && FrogEntity.isValidFrogFood(target)
 && !this.isTargetUnreachable(entity, target)
 && target.isInRange(entity, 10.0)

在这种情况下，'Sensor#testAttackableTargetPredicate' 调用了 'TargetPredicate#test'
当一个区域内有太多实体时，这会导致大量的光线投射计算，
更糟糕的是，考虑到 Minecraft 的光线投射速度极慢

在这种情况下，'TargetPredicate#test' (800 只青蛙) 每游戏刻耗时 9.8ms，
而 'BlockView.raycast' 贡献了 7.3ms

因此，我将其改为：

FrogEntity.isValidFrogFood(target) &&
 entity.getBrain().hasMemoryModule(MemoryModuleType.HAS_HUNTING_COOLDOWN) &&
 target.isInRange(entity, 10.0) &&
 Sensor.testAttackableTargetPredicate(entity, target) &&
 isTargetUnreachable(entity, target);

'isValidFrogFood' 是一个简单的条件，它检查实体的 'frog_food' 标签
以及当实体是史莱姆时额外检查其大小是否为 1

'isInRange' 和 'hasMemoryModule' 也没问题，因为它们只计算一些简单的东西

-- 状态 --
默认启用

800 只青蛙挤压在 7x7 空间内：

青蛙注视目标筛选器

使用 'SepalsLivingTargetCache' 来提高目标搜索性能
你必须启用该选项，否则此功能与原版相同

-- 注意 --
光线投射在 TargetPredicate 测试中
位于 'findFirst' 在 LivingTargetCache 中，当输入谓词成功时

但如果后续条件失败，进一步计算这个就没有用了
因为即使 findFirst 找到了（光线投射成功）
但我们没有在后续上下文中使用这个结果

-- 状态 --
默认启用

800 只青蛙挤压在 7x7 空间内：

| 原版

(LookAtMobWithIntervalTask$$Lambda#findFirst) | 2.7 ms | 100 % |

| Lithium

(LookAtMobWithIntervalTask$$Lambda#findFirst) | 2.5 ms | 92 % |

| Sepals

(SepalsLookAtMobWithIntervalTask$$Lambda#findFirstPlayer) | 0.1 ms | 3 % |

| Sepals + Lithium

(SepalsLookAtMobWithIntervalTask$$Lambda#findFirstPlayer) | 0.1 ms | 3 % |

村民杂项优化

这是 Sepals 所做的：

1. 使用 Catheter 替换 Java 的 Stream，因为它在性能和可扩展性方面比 Stream 好得多
2. 缓存任务、活动、运行中的任务和记忆，以提高启动和更新任务的时间
3. 使用 sepals 复合任务替换原版复合任务
4. 尽可能寻找机会跳过更多的光线投射和无用的谓词
5. 使用 'SepalsLivingTargetCache' 替换原版缓存，以传感器刻中的成本换取在查找交互目标或注视实体任务中更低的成本
6. 重新安排谓词和额外的低成本谓词，目的是稍后执行高成本谓词，或者最好不执行，提前跳过剩余的高成本谓词
7. 复制并修改了来自 lithium 的 'SerializingRegionBasedStorage' 优化
8. 使用更具针对性的任务，不使用泛型来减少无用操作
9. 使用二分搜索列表替换哈希集搜索

-- 注意 --
建议将此功能与 Lithium 和 C2ME 一起使用以获得最佳性能

-- 警告 --
未经长期稳定性测试，仅一个月的运行显示目前正常
此功能尚未被证明与原版完全相同，
但也未出现统计上的差异

-- 状态 --
默认启用

800 个村民在中午挤压在 7x7 空间内：

800 个村民在夜晚挤压在 7x7 空间内：

谓词优化

1172 只青蛙挤压在 3x3 空间内：