Avaritia itself is often the reason a player builds enormous production systems, but the visible lag usually comes from the infrastructure created to feed those systems. Performance work therefore needs to focus on the whole pack.
Profile throughput systems, not only memory
More RAM can prevent allocation pressure, but it does not fix expensive per-tick logic. Measure active machines, pipes, storage networks, chunk loaders, item entities, and scripted events before assuming the problem is memory capacity.
Prefer batched logistics over loose item movement
Huge crafting goals encourage massive item transfer. Keep resources inside storage or transport networks where possible instead of allowing thousands of dropped entities, open inventories, or constantly scanning transfer blocks.
Chunk loading should match production goals
A factory that runs everywhere all the time can turn a single-player world into a permanent server workload. Load only the chunks that must remain active, and verify that cross-dimensional systems are not duplicating unnecessary work.
Recipe scripts can become runtime systems
Datapacks and scripting platforms are powerful, but poorly scoped events or repeated scans can add tick cost. Keep Avaritia customization data-driven where possible and avoid scripts that repeatedly recompute static recipe information.
Client FPS and server TPS are different problems
Infinity effects, particles, custom rendering, and complex interfaces can affect frame rate, while automation affects server tick time. Diagnose the correct side before applying graphics settings or server optimizations.
Use staged scaling
Build production in measurable stages and record the effect of each expansion. When a performance cliff appears, the last stage gives you a concrete system to profile instead of a vague “large base” problem.
Related guides
Continue with another focused guide from the Avaritia resource library.