FastEvent

Проект заброшен

Короче говоря, подход оптимизации по-прежнему применяется, но Forge/NeoForge не позволяет моду изменять EventBus.

В отличие от классов из Minecraft или самого Forge, EventBus загружается не как часть игры, а как «библиотека», что делает невозможным модификацию EventBus через Mixin или Transformer.

В версии 1.2.0, стремясь еще больше улучшить производительность, я применил грязный хак (или «нестандартный подход», если хотите) для модификации класса ASMEventHandler, который, к сожалению, не работает в версии 1.18.2+. Эти выпуски сейчас заархивированы и, скорее всего, не будут получать дальнейших обновлений.

Быстрое событие

— это мод оптимизации Forge/Neoforge, который оптимизирует одну из самых фундаментальных систем Forge: систему событий.

Как быстро

Нелегко создать тестовый пример для каждой поддерживаемой версии Minecraft, особенно если системы событий для этих версий отличаются друг от друга. Поэтому вместо этого я предоставлю тест-отчет JMH из PR, который я сделал для проекта Cleanroom, в котором я использовал тот же подход к оптимизации, что и FastEvent:

Зарегистрируйте 10 000 прослушивателей событий, опубликуйте событие 0 раз:

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

Примерно на 6,4% быстрее.

Зарегистрируйте 1000 прослушивателей событий, опубликуйте событие 10 000 раз:

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

Примерно на 24% быстрее.

###Оригинальный пиар

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

Как это работает

(Предупреждение о технических подробностях)

Когда разработчики используют @EventBusSubscriber и/или @SubscribeEvent для подписки на обработчики событий, EventBus не может магическим образом получить обработчик событий, вместо этого доступен только объект Method. Поэтому наиболее простой подход — использовать этот объект напрямую: method.invoke(...). Этот вызов в конечном итоге будет перенаправлен JVM обратно к исходному методу, что позволит обработчику событий получить событие после подписки на него.

Но это (method.invoke(...)) очень медленно. Чтобы сделать это быстрее, EventBus во время выполнения будет генерировать классы обработчиков событий для каждого найденного метода, устраняя дорогостоящий вызов на основе отражения.

Но создание классов приводит к еще одному замедлению. Чтобы сделать это еще быстрее, FastEvent заменил генерацию классов на лямбда-конструкцию, ускорив создание обработчика событий. Еще одним преимуществом является то, что лямбда «скрыта», что позволяет JVM выполнять дополнительную оптимизацию.

Если вы немного разбираетесь в Java, приведенные ниже примеры кода могут быть для вас более интуитивно понятными:

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;