[bug: [Performance] YAWP lightning region/flag checks are very expensive with Ars Nouveau / Ars Elemental lightning effects

[MRMDevStudios]

Used Minecraft Version

<1.20.1

Used Modloader

NeoForge

Modloader Version

21.1.215

Bug Description

Summary

On our NeoForge server (ATM10), we’re seeing major tick-time spikes when players use Ars Elemental / Ars Nouveau spell effects that generate lightning. Those effects appear to trigger NeoForge’s lightning-strike hooks, which then causes YAWP to run region/flag checks at a very high frequency, consuming a large portion of the server tick.

This looks like a performance/compatibility hotspot between Ars’ LightningEntity and YAWP’s onLightningStrikeOccur handling.

---

What we’re seeing (from profiling)

Ars Nouveau’s lightning entity is ticking and calling into NeoForge’s lightning strike event pathway, which then calls YAWP’s lightning handler:

• com.hollingsworth.arsnouveau.common.entity.LightningEntity.tick() (~87.56%)
  • net.neoforged.neoforge.event.EventHooks.onEntityStruckByLightning() (~29.59%)
    • de.z0rdak.yawp.handler.flags.WorldFlagHandler.onLightningStrikeOccur() (~26.46%)
      • de.z0rdak.yawp.api.FlagEvaluator.processCheck() (~19.44%)
        • de.z0rdak.yawp.api.FlagEvaluator.evaluate() (~18.38%)
          • findResponsibleRegion() / getInvolvedRegionsFor() (~17.17%)
            • Java stream pipeline (ReferencePipeline.collect etc.) (~9.13%)
            • de.z0rdak.yawp.data.region.RegionDataManager.getRegionsFor() (~8.03%)

(We have a spark call tree screenshot showing the above stack + percentages.)

---

Impact

• Noticeable TPS drops / tick spikes during lightning-heavy spell usage.
• The overhead scales with:
  • number of lightning entities/effects active
  • frequency of lightning strike events

---

Mods / Environment

• YAWP (Yet Another World Protector): yawp-1.21.1-neoforge-0.6.0-beta1.jar
• Ars Nouveau: 1.21.1-5.10.6 (stack includes com.hollingsworth.arsnouveau.common.entity.LightningEntity)
• Ars Elemental: 1.21.1-0.7.6.9 (spell/effects chain that triggers lightning frequently)
• NeoForge: 21.1.215
• Modpack: ATM10 - 5.4

---

Suspected cause

YAWP appears to run a full region/flag evaluation for every lightning-strike event, including lightning produced by Ars’ custom LightningEntity. Some Ars Elemental lightning effects can generate these events frequently, which leads to YAWP repeatedly doing:

• involved-region resolution (getInvolvedRegionsFor)
• stream-based collection logic (alloc/overhead)
• region lookups (RegionDataManager.getRegionsFor)
• flag evaluation

---

Possible improvements / ideas (even as optional configs)

Any of these would help reduce the hot-path cost:

1. Fast-path skip lightning checks when no regions in the dimension/world use the lightning-related flags (precomputed “flag present” map per dimension).
2. Cache region lookups (getRegionsFor) for the duration of a tick or by chunk position to avoid repeated queries in the same area.
3. Replace Java Streams in the hot path with imperative loops to reduce allocations and overhead.
4. Compatibility/ignore option: allow ignoring “modded lightning” sources (or specifically Ars Nouveau’s LightningEntity) via config, or treat them differently than vanilla lightning.

---

Temporary workaround request

Is there a recommended config/flag to disable lightning-strike checks (or the relevant lightning-related flag evaluation) to mitigate this until it’s optimized?

---

Attachments

• Spark profiler call tree screenshot (showing the stack + percentages above)

Steps To Reproduce

1 - install above mods / modpack
2 - make a spell using lightning and lots of aoe
3 - use spell... massive lag spike

Additional Context

No response

[Z0rdak]

Note:
In the most recent version (0.6.3-beta1) region indexing/caching (spatial hashing) was added as a test for faster lookups of involved regions for a particular position in the world.
After more testing, this could be streamlined and generalized to replace the previously naive contains(BlockPos pos) checks.

This would reduce the lookup complexity as follows:

Old:

1. Looping through regions of the dimension - O(n)
2. checking contains(...), which is depending on the region area type (Cuboid vs. Sphere vs. ...) more or less performant
3. Looping again over the remaining regions to determine the region with the highest priority.

New:

1. Grabbing all the indexed regions for the position - O(1)
2. Looping over the subset of regions to to determine the region with the highest priority. - worst case O(n) but best and average case is way more likely.

So step 1 in the new approach would replace step 1 & 2 of the old approach.
This could be further improved by caching the highest priority region for a particular position/index in the world (somehow include the priority with the indexing) in case the subset of regions is still big.
Which is unlikely for most setups because the indexing is done in subchunks/sections in the world - so 16x16x16 blocks.

Further improvement:
Disable specific flags by adding a mixin loading config. But this will be a more distant future thing than the suggested optimization.