use a ConcurrentHashMap for BiomeManager

[tahmid-23]

synchronized getByXXX methods make biome loading quite slow when loading instances concurrently

[Dovias]

I'm pretty sure fastutil Int2ObjectOpenHashmap should be left there and instead of concurrent maps, to improve this, we should use ReentrantReadWriteLock to improve the concurrent performance when retrieving a biome (which synchronized keyword does not allow to read from multiple threads concurrently). I might be wrong, though.

[Steanky]

I'm pretty sure fastutil Int2ObjectOpenHashmap should be left there and instead of concurrent maps, to improve this, we should use ReentrantReadWriteLock to improve the concurrent performance when retrieving a biome (which synchronized keyword does not allow to read from multiple threads concurrently). I might be wrong, though.

If I recall correctly, during benchmarking me and @tahmid-23 discovered that a ConcurrentHashMap performs better than an RWL-gated Int2ObjectOpenHashmap, probably due to less overhead (RWLs actually incur a fair bit of overhead when reading, even if they do allow concurrent access).

The best option here, IMO, is to use copy-on-write semantics for the maps. This incurs a high overhead for writes (which are fully synchronized, unlike ConcurrentHashMap), but I think most usage patterns will feature very infrequent writes. Reads have no synchronization overhead and can use a fastutil map -- this makes them quite fast.

You can see such an implementation here.

[tahmid-23]

I'm pretty sure fastutil Int2ObjectOpenHashmap should be left there and instead of concurrent maps, to improve this, we should use ReentrantReadWriteLock to improve the concurrent performance when retrieving a biome (which synchronized keyword does not allow to read from multiple threads concurrently). I might be wrong, though.

If I recall correctly, during benchmarking me and @tahmid-23 discovered that a ConcurrentHashMap performs better than an RWL-gated Int2ObjectOpenHashmap, probably due to less overhead (RWLs actually incur a fair bit of overhead when reading, even if they do allow concurrent access).

The best option here, IMO, is to use copy-on-write semantics for the maps. This incurs a high overhead for writes (which are fully synchronized, unlike ConcurrentHashMap), but I think most usage patterns will feature very infrequent writes. Reads have no synchronization overhead and can use a fastutil map -- this makes them quite fast.

You can see such an implementation here.

but its uglier

[mworzala]

This will come with #1937 (it was merged into minestom-ce here: hollow-cube#39). I am in agreement with @tahmid-23 that the proposed implementation by @Steanky is super ugly. If you have solid benchmarks and/or use cases where you can demonstrate that the performance difference is relevant, I am interested.