Reduce Memory Allocations in ExpireTemporaryTask for Better Scalability at High Player Counts
Closed this issue · 2 comments
Description
hello there
We’ve been running LuckPerms on a large network with over 1,000 concurrent players, and while everything works great functionally, we’ve noticed through Spark profiler that there’s quite a bit of memory allocation churn coming from the ExpireTemporaryTask, especially around objects like PermissionNode, PermissionData, HashMap, and HashSet.
This leads to frequent GC activity and some memory pressure, even though we’re not hitting limits. It doesn’t crash or error — everything runs — but there’s a noticeable impact on stability under peak load.
I know performance at scale is always tricky, but would it be possible to take a look at this area and see if there are any small optimizations that could reduce object creation during temporary permission checks? Even minor improvements — like reusing certain data structures, batching work, or reducing redundant tree rebuilds — could make a big difference for large networks.
Reproduction Steps
Run Velocity server with LuckPerms and Redis (for large network setup).
Connect >1,000 real players.
Expected Behaviour
Even under high load (1,000+ players), LuckPerms should handle temporary permission expiration with minimal object allocation. The ExpireTemporaryTask and related components should:
Avoid creating redundant objects (e.g., PermissionNode, PermissionData, maps, sets) during each run.
Reuse or cache data where possible instead of rebuilding everything from scratch.
Process expiring permissions efficiently — ideally in batches — without generating excessive garbage.
Keep GC pressure low so large servers don’t experience memory-related hiccups.
We’re not expecting zero allocations, of course — just a more optimized pattern that scales better. Even small improvements would make a meaningful difference for large networks.
Server Details
velocity 3.4.0
LuckPerms Version
luckperms 5.5.9
Logs and Configs
No response
Extra Details
No response
The commit above should help a little bit :)
Worth noting that task runs every 3 seconds - so it may be more frequent compared to the other scheduled tasks on the proxy. Please give that build a try and let me know how it looks. It can probably be improved further but would need to have the actual spark report to do so.