Optimize Player#canSee

[MrKinau]

Replaces the invertedVisibilityEntities HashMap with an OpenHashMap for better performance in Player#canSee.

[electronicboy]

These collections are not designed for performance, they're designed for reducing memory overheads; I think that in these high read low write situations they tend to perform better, however

(The lack of benchmarking makes it pretty hard to say if this is a real win, however)

[Malfrador]

canSee performance can be a limitation if you have a lot of otherwise cheap entities (e.g. displays), so generally making improvements here seems sensible to me.

However some benchmarks would be interesting. Did you do any? The OpenHashMap won't be automatically faster in all cases and just blindly replacing it without proper benchmarking isn't great.

[MrKinau]

However some benchmarks would be interesting. Did you do any?

I did see some non-optimal spark reports with canSee using quite some time of tick and tried to improve it. There may be more room for improvement, but just this small change seems to be a good addition to reduce the time it needs for the containsKey. I do not feel comfortable sharing the spark reports publicly, but I'll attach some images. Those spark reports may not be 100% comparable, but they are taken on the same server and ig only the player count / player activity should make a difference.

Edit: The reports are not comparable, main issue was the consistently increasing invertedVisibilityEntities, which got fixed by: https://github.com/PaperMC/Paper/pull/11598

HashMap

Fastutil OpenHashMap

[kennytv]

In local benchmarks, misses are about 20% faster, but hits more than twice as slow once you go past a few dozen entries of hidden entities. Lynx suggested reducing the number of calls to the method from ChunkMap instead.

switching the collection here might still be a good tradeoff though