Shopkeepers

Shopkeepers

2M Downloads

~2% of server CPU spent only only your EnityDamageEvent handler?

BigScary opened this issue ยท 3 comments

commented

I reviewed your code on Github briefly and it seems to me you're going straight to looking for a metadata tag. Maybe it would be more performant to check entity type against the list of types enabled to be shopkeepers first?

https://timings.aikar.co/?id=c5c144993dcd4720adcc115cda2a56c9

commented

I have already attempted some optimization for this in v2.11.0 (you seem to be using v2.10.0, latest is v2.12.0). I think to remember that this didn't make that much of a difference in my testing. However, since you seem to have a lot of damage events going on on your server, it would be interesting for me if you could test this (ideally with a comparable situation) with the latest version of Shopkeepers and provide me with a timings report of that.

I have one more idea for improving this (without losing the genericness of the current solution), however, a baseline to compare that to would be useful.

commented

On the latest version (without further optimizations) the performance already seems to be a lot better: https://timings.spigotmc.org/?url=iqumuvuhat (10 minutes test: https://timings.spigotmc.org/?url=pehebuwofo).

I tried to replicate your situation with around ~20+ damage events per tick and only got 0.03% of tick time spent on this.
So I assume that this is already no longer an issue on the latest plugin versions. But it would be nice if you could confirm that.

Edit: I tested with damaging a shopkeeper entity. Testing with a non-shopkeeper entity (more typical situation) I get slightly worse timings (0.07%), but still a lot better than the linked timings report: https://timings.spigotmc.org/?url=ubodayumit (longer running: https://timings.spigotmc.org/?url=jalelofiji)

commented

Although I think that this has already been improved for the most part in v2.11.0, I was able to further improve the performance of this (and several other things) in v2.13.0. I therefore consider this issue to be resolved.