Optimize packet event handling

[Jeleyk]

Optimize packet event handling

Summary

Added efficient packet type mapping to avoid processing unnecessary checks and optimized packet event handling by only iterating over relevant handlers

I've tested basic scenarios (fly, hitboxes), but I believe this needs a thorough review before merging, as I could have inadvertently disrupted the logic of individual handlers.

Performance improvement

I observed high CPU usage during the processing of large numbers of clientbound packets, especially during high-traffic scenarios. After implementing these optimizations, CPU consumption was significantly reduced.

The main optimization changes the packet handling mechanism to use a hashmap of packet types to handlers instead of iterating through all registered handlers for every packet. This maintains the same logical behavior while dramatically improving performance.

[MachineBreaker]

Cant you register different handlers? Dont see why to run against all packets (for the noReminderTicks setters)

[Jeleyk]

Yes, it is possible to register multiple handlers. I tried to keep the original handler logic, and in this class under the condition (isViaPleaseStopUsingProtocolHacksOnYourServer && player.inVehicle()) we need to set noReminderTicks to 0 on absolutely any incoming packet. I assume this is redundant behavior, but I'm hesitant to change the original handler logic.

[Jeleyk]

I also had to register handlers for all packets in some other classes, since that was done in the original. Most of the time it was handlers like this:

registry.registerHandler(event -> {
            if (player.gamemode == GameMode.SPECTATOR || isTickPacket(event.getPacketType())) {
                hasInteracted = false;
            }
        });

[ghost]

this packethandlerregistry thing seems cool, you should probably PR this to packetevents though so all plugins can benefit.

[Axionize]

Could you join the Discord? https://discord.gg/Z5q8ubSW

As a project maintainer I'd like to talk to you about this in detail with less lag time.

[Axionize]

Also @Jeleyk do you by chance have a spark profile showing the performance cost of processing these listeners? I want to make sure we're optimizing for the right thing here, as generally in Grim the highest CPU usage comes from PE's wrapping, writing, and decoding of packets and little if none at all from the actual execution of the listeners themselves.

[Jeleyk]

I'm already on discord. My tag: jele__. I took these measurements for 2.5 months and I don't have any saved reports, but I can say that the manifestation of high CPU consumption was with a lot of Server2Client packages, and as far as I remember there was an emphasis on iterable stub and similar things with multiple iterations. I can re-do the measurements if necessary.