Potentially HUGE optimisation: Read/write to the scoreboard using the *saved* life count not the scoreboard one #3

New Issue

TheTechRobo · 2022-03-18T23:06:09Z

TheTechRobo commented

2022-03-18 23:06:09 +00:00

Right now, each scoreboard is stored in a <String, Scoreboard> HashMap. This is a remnant of when the life count wasn't persisted on server reboots. Now we can just generate the scoreboards on-the-fly whenever they're updated, using the current life count from the persistent storage. Performance along with RAM impact (i.e. how much we save by not storing each scoreboard separately from Bukkit) should be tested. I have no idea how to do that, though, so could someone that actually knows what they're doing in Java provide some advice?

TheTechRobo added the

enhancement

help wanted

labels 2022-03-18 23:06:09 +00:00

TheTechRobo commented

2022-11-04 15:33:30 +00:00

This actually wouldn't lower RAM usage that much. Because we're just storing a pointer to the scoreboard, the only danger of the current strategy is a memory leak - the garbage collector won't run on a scoreboard that Bukkit drops if we still have a pointer to it.

Sign in to join this conversation.