Update to Packetevents

[ComingFlex]

Description

Прошу переделать плагин. Чтобы вместо ProtocolLib использовать плагин PacketEvents. Он гораздо более оптимизированный. ProtocolLib сильно нагружает сервер.

Please redo the plugin. To use the Packet Events plugin instead of ProtocolLib. It is much more optimized. ProtocolLib loads the server heavily.

Proposed Behaviour

PacketEvents

Extra Details

Server Version PurPur 1.20.1

[ComingFlex]

https://github.com/retrooper/packetevents?tab=readme-ov-file

[Ingrim4]

Can you please provide the spark link to the screenshot?

[ComingFlex]

https://spark.lucko.me/sbIJmifZh6

[ComingFlex]

/protocol timings

[ComingFlex]

Online recording for 8-10 people
https://spark.lucko.me/7wwawB8aWE

[Ingrim4]

That is a common misconception about ProtocolLib. Spark cannot accurately measure ProtocolLib’s real impact because it uses proxy classes to interact with the Netty channel and event loop. A proxy class acts as an intermediary, forwarding method calls to the actual underlying object (in this case, Netty). Because of this, any calls marked in red areas are not directly caused by ProtocolLib but rather by Minecraft itself.

Only the green sections represent ProtocolLib, but even that is not entirely accurate—anything related to the postPacketToListeners method is actually the listener code of other plugins and should not be attributed to ProtocolLib.

The screenshot below demonstrates this perfectly:
Out of 2163 seconds, only 56ms were spent on the main thread by Orebfuscator and 6ms by AntiRelog.

/protocol timings

Furthermore, your second Spark report shows no impact that is attributable to ProtocolLib, as previously mentioned. No ProtocolLib code was invoked directly.

So no, ProtocolLib isn’t the giant CPU hog some people claim it to be. If you don’t believe what I’m saying, then I can’t help you.

[ComingFlex]

But then what loads the server? If you remove orebfuscator and ProtocolLib, this load disappears.

[Ingrim4]

Orebfuscator consumes a significant amount of CPU because it must process each block in every chunk sent to each player individually. To put this into perspective, consider the following example:

• Server View Distance = 10
• Players = 10
• Chunks per player = (11 × 11) = 121
• Blocks per chunk = (16 × 16 × 128) = 32,768

This results in 39,649,280 blocks that need to be obfuscated if ten players join simultaneously. As a result, CPU usage remains high, even if we used packet-events. The only ways to improve performance are through:

• Configuration tweaks in Orebfuscator
• Increasing the number of CPU cores
• Utilizing more threads

[Ingrim4]

Spark doesn't capture off-thread activity by default, which is why Orebfuscator doesn't appear as a major CPU consumer. However, you might be able to track Orebfuscator's threads specifically using the following command:

/spark profiler start --thread ofc-.* --regex

This attempts to capture only Orebfuscator-related threads, though I'm not 100% certain if it works as expected.

Alternatively, you can capture all threads with:

/spark profiler start --thread *

[ComingFlex]

https://spark.lucko.me/ESRQgBPpbd

[Ingrim4]

I'm mean according to your sparks report everything runs buttery smooth:

[ComingFlex]

Вы меня похоже неверно поняли. Конкретно ваш плагин не нагружает сервера. А ProtocolLib несёт нагрузку, поэтому прошу добавить поддержку PacketEvents

You seem to have misunderstood me. Specifically, your plugin does not load the servers. And ProtocolLib carries the load, so please add Packetevent support.

[Ingrim4]

I don’t think you’re understanding my point (or maybe just choosing not to). What I’m saying is that ProtocolLib isn’t actually loading your server — Netty is. Minecraft uses Netty internally, so any Netty code wrapped by ProtocolLib (ProtocolLib wrapped every single thread) appears as ProtocolLib in the profiler, when in reality it’s just core Minecraft functionality. Removing ProtocolLib won’t significantly reduce the load — at most you might see a 0.5–1% improvement per tick, which is around 0.5ms.

[Sneyzi]

+1, it's a good idea because ProtocolLib takes a long time to update to the latest versions, while packetevents has faster support.