Sepals
Sepals mod represents a revolutionary experimental approach to optimizing Minecraft server performance. This is a comprehensive solution that fundamentally reworks the game's internal mechanics to achieve maximum efficiency.
Compatibility with Other Mods
Sepals demonstrates excellent compatibility with most popular optimization mods. For best results, it's recommended to use it in combination with other optimization solutions.
Verified Combinations:
- Sodium - all versions
- Iris - all versions
- FerriteCore - all versions
- Krypton - all versions
- Lithium - versions 0.18.0 and above
- C2ME Fabric - versions 0.3.4.0.0 and above
- Moonrise Opt - versions 0.6.0-beta.1+45edfd7 and above
- Async - versions 0.1.7+alpha.7-1.21.8 and above
Special Compatibility Note
When using Sepals and Async mod simultaneously, results may vary depending on the platform. It's recommended to test different configurations by disabling individual features of each mod to determine the optimal combination for your server.
Configuration Settings
The mod offers a flexible configuration system allowing fine-tuning of optimization for specific needs:
forceEnableSepalsPoi- forced enabling of point of interest optimizationenableSepalsVillager- villager behavior optimizationenableSepalsFrogLookAt- improvement of frog observation mechanismenableSepalsFrogAttackableSensor- optimization of frog attack sensorsenableSepalsLivingTargetCache- caching of living targetsnearestLivingEntitiesSensorUseQuickSort- use of quick sortenableSepalsBiasedLongJumpTask- optimization of jump tasksenableSepalsEntitiesCramming- improvement of entity cramming processingenableSepalsItemMerge- optimization of item mergingenableSepalsQuickCanBePushByEntityPredicate- acceleration of push predicates
Performance and Testing
Testing was conducted on Mars server with Intel i7-14700K processor, 4 GB RAM running Ubuntu 24.04.1 LTS in Minecraft 1.21.
Entity Cramming Optimization
Using cache to prevent excessive 'getOtherEntities' calls
-- Important Note --
This feature ignores scoreboard/team predicates for individual entities
which may lead to unexpected behavior
This problem doesn't affect vanilla gameplay (survival and creative)
and is only relevant for servers using command blocks
-- Status --
Enabled by default
1390 villagers in 7x7 space:
| Environment | Processing Time | Performance |
|---|---|---|
| Vanilla | 53.6 ms | 100% |
| With Lithium | 54.4 ms | 101% |
| With Sepals | 10.2 ms | 19% |
| With Sepals + Lithium | 8.5 ms | 15% |
Weighted Random Selection
Using binary search to replace vanilla weighted random selection
-- Warning --
This feature may not provide significant performance improvement
as it's proven that building range tables is slower than vanilla implementation
even with almost zero binary search costs
-- Status --
Disabled by default
-- Warning --
Not fully tested
Optimized Jump Task
Sepals implementation to replace vanilla jump task implementation
As mentioned above, binary search requires almost no resources
Sepals implementation builds range tables simultaneously with target generation
and uses Catheter instead of Java Stream
Also reworked jump conditions in frog brain for improved performance
-- Important Note --
This feature cannot be changed during game runtime
server restart required to apply changes
-- Status --
Enabled by default
800 frogs in 7x7 space:
| Environment | Execution Time | Performance |
|---|---|---|
| Vanilla (LongJumpTask) | 43.1 ms | 100% |
| With Lithium (LongJumpTask) | 7.5 ms | 17% |
| With Sepals (SepalsLongJumpTask) | 0.2 ms | 0.4% |
| With Sepals + Lithium (SepalsLongJumpTask) | 0.05 ms | 0.1% |
Quick Sort in Nearest Living Entities Sensors
Using quick sort via fastutil instead of Java Tim Sort
-- Status --
Enabled by default
800 frogs in 7x7 space:
| Environment | Sort Time | Performance |
|---|---|---|
| Vanilla | 3.8 ms | 100% |
| With Lithium | 3.6 ms | 94% |
| With Sepals | 2.2 ms | 57% |
| With Sepals + Lithium | 2.2 ms | 57% |
Frog Attack Target Filter
Redistribution of attack conditions
less expensive predicates executed first
reducing probability of high-cost calculations
-- Criticism of Mojang Implementation --
Original Mojang attack predicate:
!entity.getBrain().hasMemoryModule(MemoryModuleType.HAS_HUNTING_COOLDOWN)
&& Sensor.testAttackableTargetPredicate(entity, target)
&& FrogEntity.isValidFrogFood(target)
&& !this.isTargetUnreachable(entity, target)
&& target.isInRange(entity, 10.0)
In this case 'Sensor#testAttackableTargetPredicate' calls 'TargetPredicate#test'
leading to multiple raycast calculations with many entities
and Minecraft raycasting is extremely inefficient
'TargetPredicate#test' with 800 frogs took 9.8 ms per game tick
with 'BlockView.raycast' contributing 7.3 ms
New Sepals implementation:
FrogEntity.isValidFrogFood(target) &&
entity.getBrain().hasMemoryModule(MemoryModuleType.HAS_HUNTING_COOLDOWN) &&
target.isInRange(entity, 10.0) &&
Sensor.testAttackableTargetPredicate(entity, target) &&
isTargetUnreachable(entity, target);
'isValidFrogFood' - simple entity tag checking conditions
'isInRange' and 'hasMemoryModule' also simple - few mathematical calculations
-- Status --
Enabled by default
800 frogs in 7x7 space:
| Environment | Execution Time | Performance |
|---|---|---|
| Vanilla (FrogAttackablesSensor#matches) | 10 ms | 100% |
| With Lithium (FrogAttackablesSensor#matches) | 5.7 ms | 57% |
| With Sepals (SepalsFrogBrain#attackable) | 0.1 ms | 1% |
| With Sepals + Lithium (SepalsFrogBrain#attackable) | 0.1 ms | 1% |
Living Target Cache for Observation
Using 'SepalsLivingTargetCache' to improve target search performance
Requires enabling SepalsLivingTargetCache to apply this feature
-- Important Note --
Raycasting is in TargetPredicate test
in 'findFirst' in LivingTargetCache with successful predicate
But if subsequent conditions fail, further calculations are useless
because even if findFirst found result (raycast successful)
we don't use this result in subsequent contexts
-- Status --
Enabled by default
800 frogs in 7x7 space:
| Environment | Search Time | Performance |
|---|---|---|
| Vanilla | 2.7 ms | 100% |
| With Lithium | 2.5 ms | 92% |
| With Sepals | 0.1 ms | 3% |
| With Sepals + Lithium | 0.1 ms | 3% |
Various Villager Optimizations
List of improvements implemented in Sepals:
1. Using Catheter instead of Java Stream
2. Caching tasks, activities, running tasks and memories
3. Replacing vanilla composite task with Sepals implementation
4. Skipping redundant raycasts and useless predicates
5. Using 'SepalsLivingTargetCache' instead of vanilla cache
6. Redistributing predicates prioritizing less expensive ones
7. Adapting 'SerializingRegionBasedStorage' optimizations from lithium
8. Specialized tasks instead of universal solutions
9. Replacing hashset search with binary search in lists
-- Recommendation --
For maximum performance use with lithium and c2me
-- Warning --
Not long-term stability tested
month of operation showed satisfactory results
doesn't guarantee 100% vanilla behavior compliance
-- Status --
Enabled by default
800 villagers in 7x7 space during day:
| Environment | Total Time | Performance | Start Tasks | Sensors | Update Tasks | Memory |
|---|---|---|---|---|---|---|
| Vanilla | 18 ms | 100% | 9.3 ms | 5.2 ms | 3 ms | 0.5 ms |
| With lithium | 12.4 ms | 68% | 4.8 ms | 5.9 ms | 1.2 ms | 0.5 ms |
| With Sepals | 9.7 ms | 53% | 3.6 ms | 3.7 ms | 2 ms | 0.4 ms |
| With Sepals + lithium | 10 ms | 55% | 3.4 ms | 3.7 ms | 2.5 ms | 0.4 ms |
800 villagers in 7x7 space during night:
| Environment | Total Time | Performance | Start Tasks | Sensors | Update Tasks | Memory |
|---|---|---|---|---|---|---|
| Vanilla | 16.7 ms | 100% | 8.2 ms | 6 ms | 2 ms | 0.5 ms |
| With lithium | 10.2 ms | 61% | 3.2 ms | 6 ms | 0.5 ms | 0.5 ms |
| With Sepals | 9 ms | 53% | 3.3 ms | 4.7 ms | 0.7 ms | 0.3 ms |
| With Sepals + lithium | 8.7 ms | 52% | 2.9 ms | 4.6 ms | 0.7 ms | 0.5 ms |
Predicate Optimization
1172 frogs in 3x3 space:
| Environment | Execution Time | Performance |
|---|---|---|
| Vanilla | 49.01 ms | 100% |
| With Sepals | 22.6 ms | 46% |