Performance optimization suggestions or tutorial?

[Purplicious_Cow]

Do any of our illustrious moderators or fellow modders have some basic suggestions on performance optimizations? Especially when it comes to particularly sensitive areas such as Structure Generation, Player Tick, and other Event Handlers, onUpdates in Items/Blocks. Basically, a list of common mistakes to avoid. Seems like something that many modders could benefit from.

 

 

[delpi]

Just don't create any excessive loops or large frequent packet movement. 

 

If you do have to do something really big you can jump out of the thread and back in, but you really need to know what you are doing and understand things or it will go poorly.

 

 

[Purplicious_Cow]

Ok, getting more specific:

 

@delpi, I don't have many packets, but I do have lots of loops.

@diesieben07, my mod appears to be causing some Block Lag for users when running on a Cauldron Server in a large modpack with high usage. Never been in this position before, so trying to identify the source.

 

I will focus on streamlining some of the loops in the handlers as a first effort. I'm using several handlers and several events:

 

LivingUpdateEvent

LivingHurtEvent (several here)

BreakSpeed

HarvestDropsEvent

LivingDropsEvent

 

And a few other minor events, which are only called occasionally. If I learn anything, will post it back here.

 

 

[delpi]

your blocks are regular blocks? tile_entities?  or do you have a really big resolution on your block texture?

[Purplicious_Cow]

your blocks are regular blocks? tile_entities?  or do you have a really big resolution on your block texture?

 

Very few blocks. And they only spawn in the four dungeons. No tile entities and block texture is small. The mod is all about the items.

[Ernio]

It would be much, much better if you would just post those (in question) parts of code and say what is expected outcome.

We might be able to tell you - what to not do, or maybe a better way.

[jabelar]

You can actually time the various parts of the code that you suspect using something like this:

 

final long startTime = System.currentTimeMillis();
for (int i = 0; i < length; i++) {
  // Do something
}
final long endTime = System.currentTimeMillis();

System.out.println("Total execution time: " + (endTime - startTime) );

 

A Minecraft tick is 1/20th of a second which is 50 milliseconds, and usually the code should finish before that (otherwise you'll see lag). So anything over 1 millisecond can start to be considered significant.

 

You can get more precision us9ing System.nanoTime() but in some cases it might have trouble on multi-threaded situations.

 

Anyway, with such an approach you can actually time your code and determine what is taking significant time and furthermore prove to yourself that your attempts to fix it are working.

[Purplicious_Cow]

It would be much, much better if you would just post those (in question) parts of code and say what is expected outcome.

We might be able to tell you - what to not do, or maybe a better way.

 

Sure. Here's a typical example in my PlayerTickHandler. The structure is repeated several times (for several different items) within other Handlers and within the ItemUpdate. This is the only way I've found to get it to work (verifying if the item is in the hotbar first using a loop, and then acting upon it).

 

if (event.entity instanceof EntityPlayer) {

 

EntityPlayer entityplayer = (EntityPlayer) event.entity;

for(int i = 0; i <= 8; i++)

{

ItemStack itemchk = entityplayer.inventory.getStackInSlot(i);

if (itemchk != null && itemchk.getItem() == InventoryPets.petSpider && itemchk.getItemDamage() == 0) {

 

//do magic stuff

 

break;

}

}

 

 

First question: Is there a more efficient way to verify the existence of an item in the hotbar? It seems a waste to constantly check the hotbar using a loop.

Second question: For PlayerTickHandler, would it be more efficient to put a check of the entire hotbar first for any Items up front, and then execute on a case by case basis depending on what items are found, instead of checking one by one? (Just thought of this...)

 

For the record, the PlayerTickHandler is only used where absolutely necessary, most abilities/effects are handled in Item onUpdate.

 

[Purplicious_Cow]

onUpdate in your Item class will be called every tick as long as the Item is in a player's inventory... But you already seem to know that.

 

Yes... but I could put in a counter and have it check less frequently for the items that don't need constant attention. I'll test on a couple of items and see what it saves in cycles. Thx.

[delpi]

You are not going to bog down the minecraft tick with checking a 0-8 list unless you are doing it thousands and thousands of time a tick.

 

 

[Purplicious_Cow]

You are not going to bog down the minecraft tick with checking a 0-8 list unless you are doing it thousands and thousands of time a tick.

 

Perfect. Yeah, not seeing any more gains here, using Jabelar's tester. Once per pet in inventory, per tick. Worst case scenario, that's likely several hundred on the server mentioned.

 

Ok, maybe I was too quick to dismiss the 'packet' discussion. What about NBT Data? Right now, my achievement system leverages NBT Data and is checking (and then storing) NBT Data every tick for every item in onUpdate. Could this be a contributor? Here's what I'm going to do, regardless:

 

- Only have it check every 20 ticks

- Read only to check and then only store if something has changed (duh)

 

 

[Ernio]

Hold on. "my achievement system" - so where are you running this?

 

Achievements are one-time events which should be operated kinda like:

* You do something

* You get it

* You save it

* You read it

 

Why ticking-checks? (you said you have them somewhere)

 

EDIT:

Also, many people seem to NOT know that - NBT are LITERALLY Map<key,value>. They are just represented that way.

And yeah - they are pretty fast.

[Purplicious_Cow]

Hold on. "my achievement system" - so where are you running this?

 

Achievements are one-time events which should be operated kinda like:

* You do something

* You get it

* You save it

* You read it

 

Why ticking-checks? (you said you have them somewhere)

 

The typical Minecraft triggers didn't allow for a way for me check accurately the information I wanted for the achievements. The only reliable way I could find was through Item onUpdate, though I wasn't very efficient about it. By my 'achievement system,' I mean I needed a way to check if a user had:

- collected an item (through finding or crafting)

- collected all of the items in the same group

- collected all of the groups

- collected one item from each of the groups

- collected a certain number of items, triggers at 1, 5, 10, 20, All

 

As far as I know, there's no way to track this without using NBT Data. And it went into the Item, as onUpdate in the Item is the first time we see the item appear in an Inventory (which was what I was looking for. If you have an alternate solution, I am all ears...).

 

However, there is absolutely no reason this needs to be checked every tick. Nor stored every tick. Both of these things will be changed.

 

EDIT: Saw a decent uptick in the 'onUpdate' performance (using Jabelar's timer) by making the above change. Will definitely help overall, but will keep hunting.

 

 

 

 

 

 

[delpi]

Just off the top of my head, I would create extendedproperties for the player and track it all in there.

 

If you don't want to do that, use the persistent NBT tag on the player to store it.

[Purplicious_Cow]

Just off the top of my head, I would create extendedproperties for the player and track it all in there.

 

Sorry I wasn't clear. This is exactly what I'm doing. I update extendedproperties during onUpdate in the Item.

[Purplicious_Cow]

FWIW, and for those tracking this one, here are the optimizations I found and implemented:

 

- The change to the achievement check shown above (medium gain, across all items)

- I re-organized the player tick so it had to go through fewer conditions and fewer loops (this turned out only to be a tiny gain)

- Items were checking in onUpdate every tick to see if they needed fuel. Changed this to every 20 ticks. No perceptible difference to user. (medium gain, over several items)

- One item was mistakenly looping through OreDictionary every tick in onUpdate if durability was 0. This would have only caused lag if multiple people were using it in their hotbar and the item was at 0 durability. But still. (Lex has warned me about this before, so I only have myself to blame). (small gain, when using this item only)

- Optimized loops in WorldGen structures (combining checks into one conditional) - small gain

- Removed a BreakSpeed Handler which was slow (during testing) - small gain

 

Performance is much better after these and the above optimizations. If I had to summarize, the big fixes consisted of changing checks in onUpdate: if a routine wasn't absolutely necessary to check every tick in the Item onUpdate, then I added a loop counter so it checked between 10-20 ticks instead.

 

Note that the performance problem did not surface until the mod was being put into large modpacks and played on moderately trafficked servers.

 

Will find out more after the update is published, but I am calling this one closed. Thanks to delpi, diesieben07, Ernio, and Jabelar for the ideas and assistance.

 

Edit: Added two more optimizations I had forgotten to list

[Purplicious_Cow]

I know this forum can't get enough of this topic , so one more thing to add, building on Jabelar's idea above. You can use the below as your PlayerTick Handler (or just add the code to your own) and see the overall tick performance of your mod. It basically checks the system time every loop through the player tick, and shows the difference since last loop. Using this while playing the game may give you clues as to where a performance issue could be. For the most part, the number is a steady 0. If you see it spike above 1 for a few ticks in a row, it could be a clue there is something else going on. Please note, I see a regular spike every second or so, even in Vanilla, so keep that in mind. This is not definitive by any means, just something to help if you are looking.

 

Please also note, as diesieben07 pointed out, if it ain't broke, don't fix it. There's no need to go down this route unless you are seeing or hearing about problems.

 

 

public class PlayerTickHandler 
{

   private long millStore = 0;

   @SubscribeEvent
   public void onLivingUpdateEvent(LivingUpdateEvent event)
   {      
      
      System.out.println("Total loop execution time: " + (System.currentTimeMillis() - millStore) );
      millStore = System.currentTimeMillis();
   }
}