conclube / deluxeasyncjoinleavemessage

https://www.spigotmc.org/resources/deluxeasyncjoinleavemessage-fully-optimized-async-everything-open-source.88129/

Now, this got really awkward...

..but I do code in C#, C, Java, Kotlin, LaTeX, Haskell, PROLOG, MIPS, JavaScript/TypeScript, Rust and HTML :)

Pssst, presently I study at the Royal Institute of Technology (KTH) and I am a moderator at the SpigotMC Discord server.

deluxeasyncjoinleavemessage's Issues

more async

more async

Bad Name

An api as good as this one needs a better name. Im thinking
🥇 EpicAdvancedDeluxeASyncJoinLeaveMessageUltimateProPlusX (Now Fully Optimized) 💯

A critical flaw

There is a critical flaw in the plugin!

It's not actually fully optimized! You need to cache at least 3 copies of the config for faster access times!

too small

Not enough @NotNull / @nullable
And not enough empty lines, you need atleast 50k for it to even be considered a plugin.
Plus you forgot the 250k lines of comments that show every single page on the wikipedia.

Multiple scaling issues

The plugin as it currently is does not scale well when considering a large number of players.
There's no need to do cpu-intensive operations like Player#sendMessage while more optimized options are available, and currently each player is processed sequentially.

Proposal 1 - Packets

I suggest implementing sending the join message in a fully-asynchronous manner using packets.
While this requires handling code for different versions of the underlying server implementation, it would greatly reduce overhead by avoiding calling API methods that then need to initialize a new message packet for every player, since we can initialize the packet first and then iterate and send it.

Proposal 2 - Parallelization

The stream() call should be followed by parallel(), or even better we should implement our own workload handling to process the players online, maybe even caching Bukkit#getOnlinePlayers().

Motivation and Context

The current onJoin/onQuit algorithm is O(n), since it needs to iterate over every player sequentially.
By calling parallel(), we allow the stream to potentially consume the players in O(1).
Player#sendMessage calls CraftPlayer#sendRawMessage, which creates a new PacketPlayOutChat and also converts the "legacy" string message to a "modern" IChatBaseComponent message.

See: https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/browse/src/main/java/org/bukkit/craftbukkit/entity/CraftPlayer.java

Needs a license

I think your code should have a license, anyone could own this efficient plugin!!!

Needs more Unsafe

Creating an instance of a class calls its constructor, which is very very very extremely slow! I recommend creating all instances using the Unsafe class to ensure maximum performance.

Add strictfp to all functions

Add the strictfp keyword to all functions.
See: https://en.wikipedia.org/wiki/Strictfp