CreateOpt v2.0 - Server-side Pure Optimization Module
Core Concept: No deletion or restriction of any game content. By using techniques such as caching, object reuse, and spatial indexing, the same computations can run faster.
### 1. TickOptimizer - BlockEntity tick caching
Problem: In Minecraft, every tick (50ms) requires a tick calculation for all BlockEntities. The Mechanical Power Integration Pack contains numerous power devices (gears, conveyor belts, mixers, etc.), each of which is constantly ticking, but many of these devices' states do not actually change (such as stationary gears, conveyor belts without items).
Optimization: Cache the state hash of each BlockEntity (position + type + game time window). If the state remains unchanged, skip the redundant calculation. Re-evaluate every 20 ticks to ensure no missed state changes.
Effect: Reduces the BlockEntity tick calculation workload by 30-50%. This effect is most pronounced for mechanical power integration packages.
### 2. EntitySpatialIndex — Entity Spatial Partition Index
Question: When Minecraft searches for entities within a certain area (for collision detection, item drop search, entity interaction), the default approach is to traverse all entities and check their AABB one by one. A 120-module server may have thousands of entities, and each search requires traversing all of them.
Optimization: Store the entities in a grid of 16×16 blocks. During the query, only search the grids covered by the target area instead of conducting a global traversal. For example, to find the entities within a 3×3 area, only 9 grids need to be searched instead of all the entities.
Effect: Entity search has been reduced from O(n) to O(k) (where k is the number of entities within the nearby grid), and the collision detection speed has increased by 5-10 times.
### 3. ObjectPool - Temporary Object Pool
Question: In Minecraft, a large number of temporary ArrayLists (entity lists, block lists, rendering lists, etc.) are created per tick, discarded once used, and trigger GC (garbage collection). On an 8GB memory server, frequent GC can cause lag (stop-the-world pause).
Optimization: Maintain an ArrayList object pool. When a temporary list is needed, borrow it from the pool (which has been emptied), and return it to the pool for reuse after use. Avoid repeatedly creating and destroying objects.
Effect: Reduces temporary object allocation by 60-80%, significantly reducing the frequency and duration of GC.
4. RecipeCache - Recipe Cache
Question: Every time a player or an automated device synthesizes an item in Minecraft, the game has to go through all the registered recipes (the Integrated Modding Pack might have thousands of recipes), checking one by one if the input matches. The same input has to be re-searched every time.
Optimization: Optimize the mapping of "input item hash → recipe result". After the first lookup, for subsequent identical inputs, the cached result is directly returned, achieving an O(1) lookup. The cache size is 2048 entries, using the LRU (Least Recently Used) elimination strategy.
Effect: The synthesis query has been reduced from O(n) to O(1), and it shows significant improvement for the large number of automatically synthesized mechanical power servers.
5. TPSMonitor - TPS and Memory Monitoring
Function: Outputs the server status every 5 seconds:
- TPS: Number of ticks per second (ideal value 20; less than 15 indicates server lag)
- Tick duration: Average duration of each tick (ideal value < 50ms)
- Memory usage: Used/maximum memory and percentage
Output statistics of each optimization module every 60 seconds:
- Tick cache hit rate
- Object pool hit rate (reuse vs. new creation)
- Formula cache hit rate
- Number of indexed entities in space
Purpose: Administrators can use the logs to understand the server's operating status and optimization effects, with pure monitoring without intervention.

configuration files

configuration item

createopt