@RcExtract As I explained, the timing of your tests is not even remotely accurate. You say yourself that the execution times of your tests varies by the magnitude of the result itself, which should immediately raise a flag to say that they are not accurate! Just to settle this, I have done some testing (not on a Bukkit server, because the execution time is so long it would crash the server, but I have done my best to replicate the conditions). After about 5 billion executions, the difference in execution time per execution time is roughly equal to five nanoseconds. To make such a fuss about a five nanosecond difference is almost comic. Let's say that to have any noticeable effect on the server, something would need to cause a millisecond of delay (according to my testing you would need A LOT more, but let's just call it a millisecond so we don't have to argue). For a difference of 1 millisecond to be caused by five nanoseconds delay, you would need to have 200 000 method calls in a single tick. There are two reasons why this will never ever happen: A Minecraft server will at the very most have a couple thousand players online (and even that is stretching it), so a couple thousand is the upper, upper limit for the number of player actions you need to process in a single tick. That all online players would do something in a single tick is astronomically unlikely, if not impossible. Even if tried to coordinate everyone to do something at the same time, the actions would be spread out over a couple ticks, because of human reflex times and network delays etc. etc. Let's say that the absolute maximum of player actions you could need to process in a single tick would be a thousand. This is nowhere near enough to cause any sort of difference to performance at all. Also "If you have more people on the server, Bukkit.getPlayer will become more expensive, but weak reference won't." is a total lie. Using WeakReferences/WeakHashMaps/whatever else you come up with will increase just as much as Bukkit.getPlayer(UUID) with the number of players, IE not at all. This is because the complexity of a get in a HashMap is O(1) for our purposes, meaning that the lookup time stays constant no matter how many players you have. So the difference per call will never (within a rounding error) be greater than the originally measured 5 nanoseconds. Now we have discussed why using WeakHashMaps for players is pointless, let us now discuss why it is bad. When I say that it is "complex" to do, I mean that knowing how it all works (with the garbage collector and when it does and doesn't reclaim memory) is quite complex and is not something you should have to worry about for such a simple task as keeping track of a Player, especially since the effects of getting it wrong are disastrous (mind you, even the best of programmers make mistakes). Being a good programmer is also not just about making software that runs fast, it's about choosing competent and sustainable solutions to problems, even if it means sacrificing some performance (and in this case you aren't even sacrificing any significant performance at all). Just because you can save some meaningless performance does not mean you should. After all, having all your code in one method is faster than creating methods, so why not just write all of your plugin's code in one single method? Or even better, why not write your plugin in Assembly? Then you would sure as hell save some performance, right? There has to be some rime or reason to how far you go to improve the performance of your program, and doing something which requires a quite advanced knowledge of how the JVM operates just to accomplish a simple task with very bad consequences if you get it wrong and especially instructing newcomers to do the same (meaning someone will inevitably get it wrong) all in the name of a performance benefit with doesn't matter anyway is what I'd call very unwise.