To cancel incoming and outgoing packets, ViaVersion (a plugin to support clients with versions different to the server version) throws an exception (similar to what Vanilla does to cancel packets iirc) to escape netty's writing process. Since cancelling happens quite frequently, the exception is cached and is also extending netty's En-/DecoderException to avoid wrapping and stacktrace creation in netty (instead of what would be done else, 2 lines below that).

ProtocolLib's reflection utils wrap any invocationtargetexceptions with a newly created RuntimeException, which in our case makes for 2 extra exceptions with generated stacktraces. This wouldn't be a problem normally, but does cause a considerable overhead in combination with ViaVersion's handling in a place that is easy to be avoided.

Now to the actual question: Could you either throw the underlying exception without wrapping (similar to what we do here), or do exactly that only in the 3 cases of calling netty's encode and decode method (found in your ChannelInjector class)?
It's still an extra wrapping (ReflectionEx), but the 2 layers less would still do a lot in such a hot spot 👀

Sure, that seems reasonable enough.

@kennytv can you try the latest dev build (http://ci.dmulloy2.net/job/ProtocolLib/) and see if the issue is fixed?

Here's one last case that needs to be checked https://github.com/dmulloy2/ProtocolLib/blob/master/src/main/java/com/comphenix/protocol/injector/netty/ChannelInjector.java#L472 - after doing that locally, all netty wrapping was gone 👏

Awesome, thank you!