Noticeable FPS drop while holding a GT6 tool and holding down the right mouse button


Affected version of GregTech: 6.14.11

I noticed recently while I’m holding any GregTech 6 tool (specifically tested with a Thorium Pickaxe, Shovel, Axe, Saw, and Tartarite Mining Drill (HV)) and hold down the right mouse button I get an immediate FPS drop (to about 3-10 frames per second) that lasts until I release the right mouse button. I first noticed this when using a Saw to debark logs, but further testing reveals this happens regardless of the type of block you’re aiming the tool at, and even occurs while aiming at nothing.

I also tested and determined this only happens with GT6 tools - other items (from vanilla Minecraft, GT6, and other mods) don’t have this problem.

I tested and observed this problem both in the overworld (where my FPS is always somewhat low) and in Random Things’ Spectre Dimension (where my FPS is always very high, due to the lack of mobs, tile entities, and blocks that need to be rendered).

I don’t have any further insights as to why this might be happening, unfortunately. I’m not sure if this is something that only occurs with my particular assortment of mods, or if it’s strictly a GregTech-related issue.

I did some more testing and noticed it doesn’t occur when I use my Thorium Shovel on a Burning Box (Solid, Invar). This makes me think the FPS drop occurs when the mod tries but fails to find a special use for the tool.


Which Tools are affected specifically, i need to know that. Because I am very sure its not “all tools”


I cheated in every tool listed in NEI.

The following tools are affected:

  • Pickaxe
  • Shovel
  • Axe
  • Hoe
  • Wrench
  • File
  • Screwdriver
  • Wire Cutter
  • Scoop
  • Branch Cutter
  • Butchery Knife
  • Sense
  • Plow
  • Plunger
  • Rolling Pin
  • Chisel
  • Flint and Tinder
  • Monkey Wrench
  • Bending Cylinder
  • Small Bending Cylinder
  • Double Axe
  • Construction Pick
  • Magnifying Glass
  • Scissors
  • Pincers
  • Spade
  • Gem-tipped Pickaxe
  • Hand Drill
  • Builders Wand
  • Mining Drill (LV)
  • Mining Drill (MV)
  • Mining Drill (HV)
  • Chainsaw (LV)
  • Chainsaw (MV)
  • Chainsaw (HV)
  • Wrench (LV)
  • Wrench (MV)
  • Wrench (HV)
  • Jackhammer (HV, Normal Mode)
  • Jackhammer (HV, No Ores Mode)
  • Buzzsaw (LV)
  • Screwdriver (LV)
  • Hand Drill (LV)
  • Hand Mixer (LV)
  • Monkey Wrench (LV)
  • Monkey Wrench (MV)
  • Monkey Wrench (HV)
  • Trimmer (LV)
  • Pocket Multitool (no tool)
  • Pocket Multitool (Saw)
  • Pocket Multitool (File)
  • Pocket Multitool (Screwdriver)
  • Pocket Multitool (Wirecutter)
  • Pocket Multitool (Scissors)
  • Pocket Multitool (Chisel)

The following tools are not affected (note: these are all tools you can block with):

  • Sword
  • Hammer
  • Soft Hammer
  • Crowbar
  • Club
  • Universal Spade
  • Knife
  • Pocket Multitool (Knife)

:gregory: This Version should probably be working for you. ^^

(note 1: The scary sounding Description is only there to make sure people don’t use that Version lightly.)

(note 2: if you use this Version more often, make sure your Browser didn’t cache the Download)


Thanks Greg. :slight_smile:
I’ll give this version a try ASAP to see if the problem is fixed.


Alright, I got in finally and gave that snapshot (GregTech 6.14.11-42-gcd777392 according to the Mod Info screen) a test . Unfortunately, it looks like the problem is still occurring. I tested with a Thorium Wire Cutter and a Thorium Axe.

Holding right-click when using either of those tools when aiming at nothing but air causes the FPS to drop.
Using the Thorium Axe on most blocks also causes the FPS to drop.
Using the Thorium Wire Cutter on most blocks, however, causes the tool to be swung and does not produce an FPS drop.


Gah, can you try updating to the secret version again, I might have fixed it for you this time. XD


Sorry for the delays. I finally got some time to test the snapshot (GregTech 6.14.11-43-g8aa1903f).

There’s still an FPS drop when holding down the right mouse button, although it may have improved slightly.

From my tests in the Spectre Dimension, it reduces to about 6 to 17 frames per second (from an average of about 100), which is a small increase from the previous 3-10.

I might try attaching JVisualVM to my Minecraft instance later to see if the sampler can identify where in the code the JVM is spending all of its time.


That would be awesome if you could! It’s such a substantial frame drop that whatever is happening should shoot right to the top of the listing.


I’ve also noticed this while debarking logs and doing other stuff with “world blocks” so to speak.
But never shoveling air though?

And it doesn’t happen when i hammer either, which is a bigger operation than say replacing a single log with a wood beam.

And i just learned to live with it, thinking it was just another stupid minecraft limitation.


Okay, I have some sampler results, although I don’t know how helpful they’ll be. In typical fashion, while I was sampling, the FPS drop was less severe than usual (by about 15 FPS) for some reason.

I took two sets of sampler results - one where I just let the game run normally without doing anything for several seconds, and another where I held down the right mouse button for several seconds while holding a Thorium Wire Cutter.

Sampler results before holding down the RMB:

Sampler results while holding down the RMB:

I noticed a couple of functions not found in in the first set of results make their way towards the top when this happens, namely:

Another thing I realized later might be a factor is the JVM I’m using. On the recommendation of some users over at Reddit I’ve been using OpenJ9 from AdoptOpenJDK (as opposed to Oracle’s JVM) along with some new JVM options this playthrough to improve the game’s performance.

Here are the JVM options I use:
-XX:+UseG1GC -XX:ParallelGCThreads=8 -Dsun.rmi.dgc.server.gcInterval=2147483646 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -Xmx8G -Xms8G -Xmn128M -Duser.language=en

If you think it’s relevant, I can test if the issue occurs with Oracle’s JVM as well if you want.

In case you were wondering, the reason the “jmxremote” arguments are on there is because I could only get JVisualVM to connect to OpenJ9 via JMX.


You did not sample anything i have to say. You need to actually look into the tree and open the functions until you get to a function that has rightclick in its name, the Screenshot of nothing opened does not say anything for me at all. Also please tell me if Buildcraft is actually the reason for your Lag, because I do not have Buildcraft installed at all.


Alright, I re-sampled the FPS drop and took a snapshot this time. I couldn’t find any function with “right” in its name in the results, but what I did find is that the Client Thread is receiving and processing a “S30PacketWindowItems” (presumably every tick), which ultimately winds up calling net.minecraftforge.oredict.ShapedOreRecipe.checkMatch which seems to be what is generating the client thread lag:

I thought BuildCraft might have what was sending the packets, but it looks like that thread was asleep for the entirety of the sampling period:

Edit: I looked up some of the function names in MCP. From top to bottom in the snapshot:
func_99999_d: run
func_71411_J: runGameLoop
func_71407_l: runTick
func_78765_e: updateController
func_74428_b: processReceivedPackets
func_148833_a: processPacket
func_147241_a: handleWindowItems
func_75131_a: putStacksInSlots
func_75215_d: putStack
func_70299_a: setInventorySlotContents
func_75130_a: onCraftMatrixChanged
func_82787_a: findMatchingRecipe
func_77569_a: matches

Do you have any sort of GUI open?! Specifically a Workbench?! You might be onto a different Lag Source there if you did have the Workbench GUI open.

And try to find something with the name “activate” that might help.

Edit: if you read this, you take a bit long to reply, i happen to have to “go outside” now so I cant respond within less than an hour or so…


I don’t have any kind of GUI open while I’m doing this. It’s really strange that the game is trying to update a crafting matrix I can’t even see. I tried looking up “activate” in the results as well and wasn’t getting any matches there either (I’m using the tool by holding the right mouse button while not pointing at a block, which may be why).

I think the snapshot has demystified the issue pretty considerably, though. What I think might be happening here, serverside each tick while holding one of the aforementioned affected GT6 tools with the RMB down, the code tries to find a use for it (e.g. blocking, debarking a log, emptying a burning box, changing the connectivity of a wire/pipe, etc), and then failing that it goes down a path that marks the tool as being updated (e.g. something setting an NBT value? I’m not entirely sure, I don’t have a whole lot of Minecraft modding experience.) which causes the server to send a packet to the client telling it that the inventory has been updated. Then, for whatever stupid reason, the client wrongly concludes that the crafting grid has changed and tries to find a recipe matching its new contents, and finds nothing because it’s empty (and because it’s empty and will therefore match nothing, it maximizes the amount of time it takes to scan for a matching recipe).


Sorry about that! :sweat_smile:
Didn’t mean to keep you or anything. I’m just a little indecisive when it comes to my writing, so I sometimes wind up rewriting things I write several times if I’m not satisfied with how it sounds the first few times around.


Oh great so it sends a lag packet to the client whenever rightclick is held… I wonder why it actually lags for you though, it does not seem to do that for me.

Anyways I gotta go ^^


That is such a glorious mix of happenstances to make that lag happen in code, lol. ^.^


And I am someone who likes to reply ASAP, so that I dont waste peoples time, and I didnt want to waste your time. XD

@OvermindDL1 so we should ASM this into the Mojang Code:

At Line 307:
if (i == 0) return null;

That way if the Grid is empty (which it obviously would be for the Player Inventory) it will never iterate over the entire fucking Crafting Recipe List. This should also fix some other Lag Sources while it is at it.

    public ItemStack findMatchingRecipe(InventoryCrafting p_82787_1_, World p_82787_2_)
        int i = 0;
        ItemStack itemstack = null;
        ItemStack itemstack1 = null;
        int j;

        for (j = 0; j < p_82787_1_.getSizeInventory(); ++j)
            ItemStack itemstack2 = p_82787_1_.getStackInSlot(j);

            if (itemstack2 != null)
                if (i == 0)
                    itemstack = itemstack2;

                if (i == 1)
                    itemstack1 = itemstack2;


        if (i == 0) return null; // This is the place to inject this Line

        if (i == 2 && itemstack.getItem() == itemstack1.getItem() && itemstack.stackSize == 1 && itemstack1.stackSize == 1 && itemstack.getItem().isRepairable())
            Item item = itemstack.getItem();
            int j1 = item.getMaxDamage() - itemstack.getItemDamageForDisplay();
            int k = item.getMaxDamage() - itemstack1.getItemDamageForDisplay();
            int l = j1 + k + item.getMaxDamage() * 5 / 100;
            int i1 = item.getMaxDamage() - l;

            if (i1 < 0)
                i1 = 0;

            return new ItemStack(itemstack.getItem(), 1, i1);
            for (j = 0; j <; ++j)
                IRecipe irecipe = (IRecipe);

                if (irecipe.matches(p_82787_1_, p_82787_2_))
                    return irecipe.getCraftingResult(p_82787_1_);

            return null;

Ahhh if only we could just replace the vanilla recipe list with something efficient instead…