You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 byparallel()
, 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
The text was updated successfully, but these errors were encountered: