In here, I would talk about how to improve performance on Minecraft. This tutorial may have some flaws so please help improve this thread!
I: Mods
There are a couple of mods which improve performance on Minecraft out on CurseForge these days, These are some few examples:
- Optifine: Basically your average Minecraft optimisation mod
- Betterfps: Changes sin() and cos() algorithm. There are 7 algorithms. Each one of them may or may not help you, it really depends on the hardware of your computer. Also, has some advanced features on later versions.
- FoamFix: Decreases Java heap usage by as much as 50%
- FpsPlus: Boosts your FPS by changing math functions to be either faster or less intensive.
II: Ingame Fixes
Minecraft has always some problems with
- Certain Blocks - Some blocks are just inherently laggy when a lot of them are present in one area, these include fence posts and leaves.
- Entity count - Too many animals, mobs, items on the ground etc will all cause lag.
- Light updates - The initial creation or deletion of light will cause lag due to the game having to update the block light levels
- Redstone: Due to the block updates and calculating game ticks, people think this is a cause of lag, however, this is not the huge lag inducer people think it is.
- Block updates/Entity calculation - Everything from pistons pushing blocks, water flowing out, animals or mobs jumping around in the water, TNT going off (and throwing more TNT around), sand or gravel falling can and will cause lag. Due to the updates that these induce whether it's mob behaviour or block updates (ghost blocks when using shovels much?) or entity calculation (think falling sand or TNT getting flung everywhere)
that decreases fps, here's a link to a fix to the common Redstone lag, it encases the circuit with light, which reduces light updates (which is the cause of the infamous Redstone lag) and improves fps.
III: JVM arguments
This is a very complicated process, so I suggest using the Java Argument Generator to start out, but for how each argument works, I too am not very clear, so I'm going to only cover the two garbage collectors, which I looked up in here, feel free to suggest down below!
- The CMS Collector: This algorithm uses multiple threads (“concurrent”) to scan through the heap (“mark”) for unused objects that can be recycled (“sweep”). The biggest concern when using this collector is encountering promotion failures which are instances where a race condition occurs between collecting the young and old generations. If the collector needs to promote young objects to the old generation but hasn’t had enough time to make space clear it, it will have to do so first which will result in a full STW collection – the very thing this CMS collector was meant to prevent. To make sure this doesn’t happen you would either increase the size of the old generation (or the entire heap for that matter) or allocate more background threads to the collector for him to compete with the rate of object allocation. Another downside to this algorithm in comparison to the parallel collector is that it uses more CPU in order to provide the application with higher levels of continuous throughput, by using multiple threads to perform scanning and collection. For most long-running server applications which are adverse to application freezes, that’s usually a good trade off to make. Even so, this algorithm is not on by default. You have to specify XX:+USeParNewGC to actually enable it. If you’re willing to allocate more CPU resources to avoid application pauses this is the collector you’ll probably want to use, assuming that your heap is less than 4Gb in size. However, if it’s greater than 4GB, you’ll probably want to use the last algorithm – the G1 Collector
- The G1 Collector: The Garbage first collector (G1) introduced in JDK 7 update 4 was designed to better support heaps larger than 4GB. The G1 collector utilises multiple background threads to scan through the heap that it divides into regions, spanning from 1MB to 32MB (depending on the size of your heap). This collector is turned on using the –XX:+UseG1GC flag. This strategy the chance of the heap being depleted before background threads have finished scanning for unused objects, in which case the collector will have to stop the application which will result in an STW collection. The G1 also has another advantage that is that it compacts the heap on-the-go, something the CMS collector only does during full STW collections. Another beautiful optimisation which was just out with Java 8 update 20 for is the G1 Collector String deduplication. Since strings (and their internal char[] arrays) takes much of our heap, a new optimization has been made that enables the G1 collector to identify strings which are duplicated more than once across your heap and correct them to point into the same internal char[] array, to avoid multiple copies of the same string from residing inefficiently within the heap. You can use the -XX:+UseStringDeduplicationJVM argument to try this out.
