Jump to content

Performance optimization suggestions or tutorial?


Purplicious_Cow

Recommended Posts

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.

 

 

Link to comment
Share on other sites

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.

 

 

Long time Bukkit & Forge Programmer

Happy to try and help

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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.

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

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.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

 

 

Link to comment
Share on other sites

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.

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

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.

 

 

 

 

 

 

Link to comment
Share on other sites

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.

Long time Bukkit & Forge Programmer

Happy to try and help

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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();
   }
}

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.