Performance

Note: this page assumes knowledge of Minecraft's threading. Read about it here.

RaycastedAntiESP is highly optimised, with all work performed off the main thread. Additionally, while many anticheat/antiesps instead perform their work on the player's Netty thread, RaycastedAntiESP delegates as much work as possible to a seperate async thread.

Why not work on the Netty thread?

A common design pattern, used by anticheats such as Grim, is to (almost) exclusively work on the players' Netty threads. This has many benefits. The primary benefit is that since anticheat checks are typically per-player, running on the players' Netty thread provides a single-threaded environment. This means that complex issues like cross-thread synchronisation, which incur a performance penalty and can cause difficult-to-diagnose bugs when done incorrectly, can be avoided. However, adding extra work to the Netty threads comes at a cost. If a player's Netty thread is overloaded, their packets take longer to be processed. This effectively adds lag to their connection, which is obviously not desirable.

RaycastedAntiESP's threading model

As handling packets quickly is important, RaycastedAntiESP's checks do not run on Netty. [To be continued, incomplete page]