FastEvent

Project Abandoned

Long story short, the optimization approach still applies, but Forge/NeoForge does not allow mod to modify EventBus.

Unlike classes from Minecraft or Forge itself, EventBus is loaded not as part of the game, but as "library", which makes it impossible to modify EventBus via Mixin or Transformer.

In 1.2.0, in an effort of further improving performance, I used some dirty hack (or "non-standard approach" if you prefer) to modify the ASMEventHandler class, which is unfortunately broken in 1.18.2+. These releases are archived now, and are likely not receiving further update.

FastEvent

is a Forge/Neoforge optimization mod that optimizes one of the most fundamental systems in Forge: the Event system.

How Fast

It's not easy to make a test case for every supported Minecraft version, especially when the Event system for these versions are different from each other. So instead, I will provide a JMH benchmark report from a PR I made for Cleanroom project, in which I used the same optimization approach as FastEvent:

Register 10,000 event listeners, post event 0 times:

Benchmark                               Mode  Cnt     Score     Error  Units
BusPerformanceTest.register10000Legacy  avgt    5  1126.498 ± 284.633  ms/op
BusPerformanceTest.register10000Modern  avgt    5  1058.961 ± 173.586  ms/op

About 6.4% faster.

Register 1,000 event listeners, post event 10,000 times:

Benchmark                                       Mode  Cnt     Score      Error  Units
BusPerformanceTest.register1000test10000Legacy  avgt    5  4407.963 ± 4250.643  ms/op
BusPerformanceTest.register1000test10000Modern  avgt    5  3550.578 ± 1991.352  ms/op

About 24% faster.

Original PR

https://github.com/CleanroomMC/Cleanroom/pull/328#issuecomment-2801099504

How does it work

(Nerdy technical details alert)

When devs are using @EventBusSubscriber and/or @SubscribeEvent to subscribe event handlers, the EventBus cannot get the event handler magically, instead only a Method object is available. So the most straight-forward approach is use this object directly: method.invoke(...). This invocation will eventually be redirected by JVM back to the original method, allowing an event handler to receive an event after subscribing to it.

But this (method.invoke(...)) is really slow. To make it faster, the EventBus will, at runtime, generate event handler classes for every method it found, eliminating expensive reflection based invocation.

But generating classes introduces another slow-down. To make it even faster, FastEvent replaced class generation with lambda construction, speeding up event handler construction. Another benefit is that lambda is "hidden", allowing JVM to perform more optimization.

If you happen to know a bit Java, code examples below might be more intuitive for you:

class Listen {
    public void onEvent(Event event) {
    }
}
Listen lis = new Listen();

// EventBus will generate a new class for every event handler
class IEventListener$Listen$onEvent implements IEventListener {
    private Listen instance;
    public IEventListener$Listen$onEvent(Listen instance) {
        this.instance = instance;
    }
    @Override
    public void invoke(Event event) {
        instance.onEvent(event);
    }
}
IEventListener handler = new IEventListener$Listen$onEvent(lis);

// FastEvent uses lambda to generate event handler
IEventListener handler = lis::onEvent;