[1.8] A question about performance and how to improve it.

[Samalot]

Hello, this may sound like a basic question, but I would love to hear about how you optimise your mods performance?

 

For example, I may be paranoid, but something about using event handlers that are called every tick does not sit right with me... does firing 10-20 different events cause much lag? even if there is very little to no logic happening every time?

 

I have a 'token' which amplifies the damage you do to mobs and the damage you take from mobs. The only way I could work out how to do this is to subscribe to the 'onEntityGetHurt' event and check if the player is holding the token. This means that  the actual logic for the item is in the event handler class and not in the item class. Is this bad? My code works, but sometimes I can't shake the feeling that my solution is... hacky.

 

Essentially my main questions are:

• Does using events that fire every tick cause much lag? even if you have if statements so it only does something under certain circumstances.
  
• Is it bad to have the bulk of item logic in the event handler and not in the corresponding item class?
  

However, I am also interested in hearing any other tips you have? I don't want my mod to cause unnecessary performance drops.

 

Thanks in advance,

Sam

[coolAlias]

Obviously, if you can avoid using a tick event, for example because the Item class already has #onUpdate which you can override to do things on a tick-by-tick basis, then avoid it. But if a tick event is the only way to make your mod work, then go for it - as long as you don't overdo it (avoid nested loops and recursive calls as much as possible) it has negligible impact on performance.

 

And yes, you shouldn't be putting most of your Item code in event handlers rather than the Item class itself, but depending on what you are trying to do, this may be unavoidable.

 

LivingHurtEvent is a good example - you can't use the Item AttributeModifiers since I assume the Item is not held or equipped while doing damage, so that event is really the only way you can apply your damage bonus. That's perfectly fine, especially since it sounds like you are setting up your logic to break out early and avoid processing when not necessary, which is the best you can ask for.

 

Basically: events are already pretty optimized and, in comparison to everything else that is already going on in Minecraft, require negligible processing power UNLESS you do something stupid in there

[Ernio]

Anecdote:

I remember when I stared coding stuff that heavily changed how mobs act.

Since I "come from" performance-oriented programming I was packing literally everything into generic types and operated on some weird-ass ticking (e.g not 20/sec but every 5 or cache-based stuff).

The mod itself was applying properties to every living enitity which on server reaches probably above 5000 spawned (depending on loaded area).

Using generic data and those caching systems - sure that gave me few MB RAM and maybe little part of tick, but hell - never again.

 

Seriously, as the mod expanded to current version I rewritten everything to object-oriented systems, also I no longer care about per-tick operations.

You would have to do some pretty HEAVY stuff to actually slow the game.

As of now I probably hold about more than few houdred objects per entity and do pre, mid and post tick on each of them, updating their effects, casting status, some party/guild stuff, literally everything.

On top of that I have tons of world- and server-based operations handling quests and shitload of who-knows-what.

 

Result? Hell - the mod takes next to nothing in means of performance (close to vanilla forge) and about few dozens of MB ram more.

 

I hope this will give some view on "how to not care".

 

Just note: I am not talking "don't ever care" - you should, just don't do too many micro-optimizations.

 

EDIT:

From all of bad pieces of code I've seen - most of them fail on:

* Not caring what happens interanally (e.g: calling methods that have no idea what they "actually" do), just take setBlockState - it also updates light in world if you don't use it properly.

* Recursion

* Retarded usage of if statements (seriously, order is important).

[jeffryfisher]

Minecraft performance does not seem to be limited by server-side "thinking". Nor is it (given a decent graphics card) hampered by rendering. Instead, the bottle-neck seems to be client-server communication. Bandwidth is crucial (especially for some home-hosted servers with residential connections), but ill-considered design can also run afoul of round-trip time (especially if multiple round-trips are required to coordinate a decision and its effect).

 

So be aware of the things that introduce bandwidth and round-trip delays. For example, tile entities can. It's okay to have them for truly special block devices, but you wouldn't want to replace all of the stone in the world with something generating a packet on every tick 

 

In general, if you can wrap your head around client-server software design (and if you have decent client hardware plus server bandwidth), then you shouldn't have any performance problems.