WardEventHandler.onWorldTick() repeatedly calls Chunk.getCapability() every tick, avoidable per-tick capability lookup

[BuenChico785446]

Profiling shows WardEventHandler.onWorldTick() consuming ~1.24% of total server thread time, almost entirely inside Chunk.getCapability() → CapabilityDispatcher.getCapability() (~1.13%).

This appears to be a per-tick cost rather than a one-time cost, onWorldTick() runs every server tick, and each call re-fetches the ward capability from the chunk via Forge's generic CapabilityDispatcher lookup instead of caching a direct reference.

Suggested fix:

• Cache the ward capability reference for a chunk when the chunk is loaded (e.g. in a chunk-load event), rather than calling getCapability() fresh on every tick.

• Alternatively, maintain a direct map/reference from chunk to its ward data structure, bypassing the generic Forge capability dispatch entirely for this hot path.

• Consider skipping chunks with no active wards early, if a cheap way to check that exists, to avoid the capability lookup entirely for chunks that don't need it.

This is a repeating, always-on cost (unlike worldgen-only costs), so even a modest per-tick overhead compounds over time across all loaded chunks.

[TheCodex6824]

Unfortunately, adding any sort of caching would defeat the purpose of using a capability - that someone else can override the implementation I provide and have the rest of my code work as-is. If I cache my own implementation, we would silently ignore anyone that overrode it after me.

What might help is to cache ward chunk lookups within the function call - right now we get the chunk and capability for every block that has a scheduled tick, which is not very efficient and is probably very bad in worlds with lots of redstone repeaters and such loaded. However, if there are large amounts of chunks loaded with a single affected block in them each, this won't really help.

I will look into optimizing this, but in the meantime you can enable the disableExpensiveWardFeatures option in the config to make it bypass this entire handler at the cost of the niche case of people warding blocks with scheduled ticks not preventing the ticks from happening.