So currently the ItemHammer has an internal number that it increases to 400 whenever it stuns a mob, and then slowly decrements. However, this is a global, server-wide number. I'm not sure if you wanted all stuns to be synchronised or for there to be the possibility that a stun could just never wear off.

This check is made without making sure that the weapon being used is the hammer. It didn't show up super-huge on my profiling (more on that in a moment), but depending on the speed of the implementation of the hash map, it's potentially making a lookup (which could be costly), before even checking if the weapon is a hammer.

This code here is called regardless for every living entity update event.

As you can see from this image, the most expensive part about the event handler is the HashMap.get. It's not super-expensive in regards to other things, but the expense is directly proportional to the number of entities in a world, and the more players online = the more entities loaded.

As it stands, you could chuck if (stunTimer != 1) return before the attempt to fetch the entity attribute (and remove the check after) and the event will literally do nothing for the most part.

However, obviously the implementation of stunTimer is less than ideal.

The alternative solution could be to code it as a potion effect, which modifies the attribute whenever it is applied, and then removes the attribute once the effect fades. Application would then just be a matter of applying a potion effect to the entity -- instead of changing stunTime to 400.

This allows the vanilla engine (as "optimized" as it is) to handle the ticking of the effect, while also allowing stuns to be independent of each other. Migrating this would be relatively seamless and quite simple to do; I believe there are also ways of preventing milk from removing the effect (at least Thaumcraft does this) for players.

Fixed by 606c135