Introduce PreEntitySpawnEvent
In the old ways of preventing certain entities from spawning in the world, EntitySpawnEvents could be cancelled; however, those events still had a linked NMS equivalent Entity, costing the server the processing time to set up said entity and use some JVM memory for said entity.
In the past, I've ran some tests and arrived at the conclusion that doing something as simple as preventing any Entity spawning below y=64 will cause massive object churning (and massive GCs). So, to solve this potential problem, since we are implementing the server from scratch, why not create a new event that only has a reference to the Location, the EntityType, and the SpawnReason, this way the object churning and processing from creating and setting up the entity does not take place, or at least only does so in a much smaller context.
This of course is dependent on having natural reasons for entity spawning to properly throw said event when necessary.
:+1:
I can't really assess, whether this will improve performance; but why not add it?
Nevertheless I'm asking, why instantiating an entity spawns it. The issue you mentioned above could be easily fixed by spawning the entity after the event has been called.
Nevertheless I'm asking, why instantiating an entity spawns it. The issue you mentioned above could be easily fixed by spawning the entity after the event has been called.
The entity needs to be instantiated to be customized by the event, then if the event is cancelled, the entity is GCed. That doesn't mean "instantiating an entity spawns it", but that whether it's spawned or not, it's created for the event.
@bendem: well, that entity object (and it's gc - process) wouldn't be a problem if it (first) just holds references to the world and it's location/type. As a reference: ever World#getBlockAt()/Location#getBlock() causes a new GlowBlock object to be created. Object creation / removing isn't such a problem in java itself, if the instantiation isn't. And if it would be a problem, something like Pooling would be an idea.
The problem is the event spamming. If a plugins disables all mob spawning from the EntitySpawnEvent, it creates around 4-15 entities per tick and trashes them directly.
Relevant irc log with some interesting points by @coelho
https://gist.githubusercontent.com/dequis/b800109908eecfb2dd80/raw
(if someone wants to summarize it, that would be cool. i'm just posting it here for the record)
As far as I can tell, the world EntityManager allocates "space" for an entity in the constructor. "space" refers to adding the object to the list of entities, etc, etc. Point here being that it isn't a super light-weight constructor.