Memory (RAM, -Xmx startup option)
- The default amount of memory Java allocates is insufficient for modded Minecraft. 1200 Megabytes is about the minimum reasonable (-Xmx1200M), 2000-3000 Megabytes should work well. For the client add another 1-2 GB with large mod packs, for MC 1.8+ another 1-2 GB.
- Never allocate too much RAM to Minecraft, there has to be enough remaining for the Operating System, other programs and Minecraft's off-heap data. This off-heap data doesn't count towards the Xmx setting, it's used by program code, texture/geometry buffers etc. More memory also means garbage collection has to do more work.
- Some mods leak large amounts of memory. If your game happens to slow down over time, sometimes as soon as a few minutes in, you may be suffering from a memory leak. Sometimes this can be observed by watching "Used memory" (F3 screen). The value will frequently hug the upper ceiling (100%) and only decrease marginally each time, possibly accompanied by a lag spike.
General
- Use 64-Bit Java and the most recent version.
- Be careful with custom startup options, many of those aren't helpful.
- The FastCraft config provides extra tweaking options.
Client
- Reduce the view distance as needed, helping CPU, GPU and RAM usage.
- Build performance intense structures (farms, effect heavy or dynamically rendered blocks etc.) further away. Chunks next to the player are the most expensive, they don't have their render cache updates throttled and the game won't try to cull costly geometry. Moving structures completely out of the view distance is even better.
- Mini map mods tend to have severe issues regarding performance and/or faulty threaded world accesses.
- Disable V-Sync, doing so may cause tearing artefacts, but it prevents the fps to be limited to a divisor of your monitor's refresh rate (e.g. 60/30/20/15 fps).
- Try setting "Max Framerate" to unlimited.
- Reducing particles, turning clouds off, setting smooth lighting to off, disabling or reducing mip maps (=level 0) or using the "fast" graphics mode can help.
- Turning Forge's splash screen off can reduce startup times substantially (config/splash.properties - enabled=false)
- 1.8+: Turning Forge's lighting engine off can reduce chunk rebuild times substantially (config/forge.cfg - B:forgeLightPipelineEnabled=false)
- Downgrade Optifine to a version without embedded shader support if using shaders is not desired
Server
- Try using only personal chunk loaders which are inactive while the owner is logged out or none at all.
- Restart the server often, esp. when the loaded chunk count or memory usage is unusually high (seen e.g. in "/sampler counts" and "/sampler memory --gc")
- ALWAYS run the dedicated server with the nogui parameter at the end, otherwise the GUI will frequently trigger garbage collection.
- Contrary to opposing claims elsewhere, using ParallelGC - the default in Java 8 - seems to work best and should only trigger very infrequently.
Other mods
- Optifine replaces most of the render engine to potentially boost fps. FastCraft and Optifine complement each other to a large extent, they are not doing the same thing although the end results may be similar. Be aware that Optifine may cause render glitches with some mods.
- FpsPlus replaces Minecraft's math functions with possibly faster ones, depending on your CPU.
- Opis is a general performance monitoring tool similar to Sampler, but capable of telling where some of the lag sources are in a world. It's a lot more user friendly, but uses a very different data acquisition method influencing the test environment more. Keep relative ratios in mind, if Opis says 8.000 µs, that's really just 0.016% of the total tick time (50000 µs) including the measurement overhead.
...(to be continued)
