Sampler Mod 1.12.2, — Guide
Frame Time Debug Graph
One of the most immediate features Sampler adds is an enhanced frame time graph to the standard F3 debug overlay. This graph tracks the last ~2,000 frames to show the consistency of the game's performance.
Graph Components
- Horizontal (X) Axis: Represents time, with the oldest recorded frames on the left and the most recent on the right.
- Vertical (Y) Axis: Represents frame time in milliseconds (ms). Lower lines indicate higher FPS (e.g., 16.67ms equals 60 FPS).
- Horizontal White Lines: These act as benchmarks for 0 ms (infinite FPS), 16.67 ms (60 FPS), 33.33 ms (30 FPS), and 66.67 ms (15 FPS).
Color Coding
- Blue: Time spent in the client tick (simulation logic).
- Green: Time spent in rendering, VSync, and miscellaneous tasks.
- Red Rhomb Markers: These appear at the bottom of the graph whenever Sampler detects a Garbage Collection (GC) run. If a frame spike aligns with a red marker, the lag is caused by memory management rather than rendering or logic.
Performance Analysis Categories
Sampler helps categorize lag into three main types to streamline troubleshooting.
1. Low Memory Issues
Caused when the JVM's heap space is insufficient or a mod has a memory leak.
* Symptoms: Freezes right before the F3 memory counter drops; high CPU load on all cores during freezes; "GC Overhead Limit Exceeded" crashes.
* Diagnosis: Check /sampler memory. If the last two rows (GC time) are consistently high after the first few minutes of uptime, the heap size (-Xmx) likely needs to be increased.
2. Client-Side Issues
Problems affecting the rendering thread. * Symptoms: Low FPS; stuttering when moving the mouse; freezes during chunk updates. * Diagnosis: Observe the F3 graph. If the green area is excessively high or jagged, the issue is related to rendering settings, shaders, or complex block models.
3. Server-Side Issues
Problems affecting the simulation thread (TPS lag).
* Symptoms: Blocks reappearing after being broken; delayed GUI opening; "Can't keep up" console warnings.
* Diagnosis: Use /sampler tps. If the average tick time is significantly above 50ms, use the profiling commands to find the specific entity or tile entity causing the delay.
Advanced Analysis with VisualVM
For deep-dive analysis, Sampler exports .nps files that can be opened in VisualVM, a Java profiling tool.
Analysis Workflow
- Load the File: In VisualVM, go to
File > Load, set the filter to "Profiler Snapshots," and select your exported.npsfile. - Identify the Thread: Locate the "Server thread" (for
/samplerexports) or "Client thread" (for/csamplerexports). - Verify Data Integrity: Check the "Time" vs. "Invocations" columns. Under default settings, there should be roughly 10ms for every invocation. If the numbers are wildly different, the data may be skewed by a GC run.
- Expand the Call Tree: Unfold the thread entries to see which methods are consuming the most time. * MinecraftServer.tick: High values here indicate entity or block tick lag. * Thread.sleep: High values here are actually good; they indicate the server has idle time and is not overloaded.
- Deobfuscation: Note that method names may appear as
func_12345_a. These can be translated using MCP mapping files or by identifying the parent class (e.g.,net.minecraft.entity.EntityLiving).