Optimize event dispatch when no listeners are registered

[flennium]

Fixes #14153

What does this PR do?

Optimizes Bukkit event handling in frequently executed paths by checking for registered listeners before creating and dispatching events.

Affected areas:

• Entity and vehicle collisions/movement.
• Fluid flow.
• Block physics.
• EntityInsideBlockEvent.

When listeners exist, the guarded event paths remain unchanged:

• Events are still created and dispatched.
• Event modifications still work.
• Cancellation still works.

No public API or listener registration behavior was changed.

When no listeners are registered, event dispatch is skipped while normal vanilla behavior remains.

Testing

Validated with:

• :paper-server:compileJava
• fixupSourcePatches
• rebuildPatches
• Full build
• git diff --cached --check

Listener-enabled test:

EntityInsideBlockEvent handlers: 1
Calls: 40,200
Dispatches: 40,200

Cactus health:
10.0 -> 10.0

Listener-disabled test:

EntityInsideBlockEvent handlers: 0
Calls: 40,200
Dispatches: 0

BlockPhysicsEvent dispatches: 0

Cactus health:
10.0 -> 9.0

Java Flight Recorder was used with a synthetic workload as allocation evidence:

Patched: 0 EntityInsideBlockEvent allocation samples
Baseline: 4 EntityInsideBlockEvent allocation samples

This is targeted validation evidence only and is not a production benchmark or a percentage performance measurement.

The synthetic vehicle workload did not successfully trigger the vanilla vehicle event paths, so those paths were not runtime validated.

AI Assistance Disclosure

AI assistance was used for repository inspection and implementation assistance.

I reviewed the changes, understand the implementation, and verified the results before submission.

[SirYwell]

Allocation samples are probably not a very good metric. What other measurements did you use that show a clear benefit?

[flennium]

Yeah, that's fair — allocation samples alone aren't really enough to show the actual impact. I only used them as supporting evidence that the unnecessary event allocations are being removed.

I also ran a controlled synthetic test with:

• 3 baseline runs
• 3 patched runs
• 200 tick warmup
• 600 tick measurement period
• 12 million entityInside calls per run (36 million total per variant)

The results were:

• Median tick time: 1.1855 ms → 0.9814 ms
• P95 tick time: 1.5443 ms → 1.2888 ms

Main-thread CPU time over the measurement window:

• 901.0 ms → 843.75 ms

That CPU time is for the main thread as a whole during the measurement window, not time spent exclusively inside the event-dispatch methods.

The allocation and GC numbers are just supporting evidence here, not the main performance measurement.

This is still a synthetic workload designed to isolate this specific event path, so these results shouldn't be generalized to production-scale performance.

I can also provide the raw JFR files from the runs if that would be useful.

[SirYwell]

Can you share the benchmark/workload setup? Only seeing the code that is run allows judging the results in any way.

[flennium]

The full benchmark/workload setup is included in Paper-14153-benchmark.zip.

It contains the test plugin and code used for the measurements.