Travis Watkins 74b3be57b7 Replace LongObjectHashMap with a more efficient implementation ... After further testing it appears that while the original LongHashtable has issues with object creation churn and is severly slower than even java.util.HashMap in general case benchmarks it is in fact very efficient for our use case. With this in mind I wrote a replacement LongObjectHashMap modeled after LongHashtable. Unlike the original implementation this one does not use Entry objects for storage so does not have the same object creation churn. It also uses a 2D array instead of a 3D one and does not use a cache as benchmarking shows this is more efficient. The "bucket size" was chosen based on benchmarking performance of the HashMap with contents that would be plausible for a 200+ player server. This means it uses a little extra memory for smaller servers but almost always uses less than the normal java.util.HashMap. To make up for the original LongHashtable being a poor choice for generic datasets I added a mixer to the new implementation based on code from MurmurHash. While this has no noticable effect positive or negative with our normal use of chunk coordinates it makes the HashMap perform just as well with nearly any kind of dataset. After these changes ChunkProviderServer.isChunkLoaded() goes from using 20% CPU time while sampling to not even showing up after 45 minutes of sampling due to the CPU usage being too low to be noticed.		2012-09-21 11:20:10 -05:00
..
minecraft/server	Replace LongObjectHashMap with a more efficient implementation	2012-09-21 11:20:10 -05:00