Exponential lag because of entities in 1.9

Confirmed. I tested it in 1.8.9 and in 1.9

World Download for 1.8.9 & 1.9 now available.
And confirmed for Pre-Release 1.9.1

Please link to this comment in the description

The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta.

It looks like some performance decrease is indeed caused by collision tests. For ArmorStands this is special because they use the method net.minecraft.entity.item.EntityArmorStand.collideWithNearbyEntities() to only collide with Minecarts. The problem is still that all for all entities in the collision box it is tested whether they are a MinecartRideable. The bug is probably that this method ignores the team options whereas the method net.minecraft.entity.EntityLivingBase.collideWithNearbyEntities() which is overridden takes the team options into account.

Another problem which affects the other mobs is that the method net.minecraft.world.World.getEntitiesInAABBexcluding(Entity, AxisAlignedBB, Predicate<? super Entity>) does not test if the Predicate is always false which is the case if the team collision rule value is never. Instead it still tests for every mob whose collision box intersects and never finds an entity that can be pushed.

In Minecraft 1.9 (MCP versions) I get the following number of FPS on average for 1024 ArmorStands:

Edit: It looks like the performance could be increased by having the method net.minecraft.client.renderer.entity.RenderLivingBase.doRender(T, double, double, double, float, float) test if the entity or any of its parts or items should be rendered before preparing everything for rendering or not even sending a packet for this entity to the client. This is however pretty fragile as changes to rendering could be left out by accident, which would cause new bugs.

Lag is the same in 16w15a.

I made an incredibly simple fix for this in MCP.

I am by no means saying this is the perfect fix, but there definitely is way less lag(16k ArmorStands is decently possible for me now, instead of 1k). I added three if statements to check if an armor stand is a marker armor stand. I'm not 100% sure this has no other implications, but I don't see how it could.

All changes I made were in EntityArmorStand.

In "isInRangeToRenderDist" I simply added:

if(this.hasMarker())
		{
			return false;
		}

to the beginning of the function.

In "collideWithNearbyEntities" I put everything inside:

if(!this.hasMarker())
		{
		}

In "onUpdate" I also put everything inside:

if(!this.hasMarker())
		{
		}

I think the impact of marker ArmorStands can be decreased even further, since they seem to have even less of an impact when you are very far away(and they are in spawn chunks).

This bug has been marked as Resolved, but I do not understand why.

Using the setup in the description of this bug report, the results are identical to me when using 1.9.2 versus using 16w15b. For me, the tps is still decent at 1024 armorstands(albeit noticeably lower), but becomes unplayable at 2048 armor stands.

Also, with F3 open, looking at the amount of entities, it shows them as still being "rendered". With the suggested code in my previous comment, they did not show up there anymore, just in the total entity count.

Perhaps the patch for this bugfix was not applied?

The first part of your patch probably makes all Marker:1b ArmorStands invisible, even if their Invisible tag is set to false. The second part might cause problems if the pose of the ArmorStand is changed. However besides that it would probably increase performance.

Ah of course, that is correct. I had assumed marker armor stands were supposed to be always invisible, unaffected by gravity, etc. I feel like they should be, but that's more of a feature request than anything.

I assume they should still not push entities/get in minecarts though, which should increase performance a lot.

Marker-AS should also in my personal opinion definitely not be pushable upwards by pistons (MC-100398) or interfere with any entities/minecarts, like @unknown said.
Back when Marker-AS rendered itself incl. their equipment (MC 1.8.1 iirc, was a bug) invisible, they also vanished from the rendered entity count, which helped with lag, as the majority of lag came from the rendered entity count, comparably less from the overall entity amount itself (at some point it also does, of course).

Exactly the same for me in 16w15b as well. Definitely not fixed - possibly even slightly worse than 16w15a: https://youtu.be/vqYrmGKWH8A?t=36s

Confirmed for 1.9.3, dropping from ~950 FPS without AS to ~350 FPS with 100 AS.
Back in 1.8.x I could handle ~2.500 entities with ~120 FPS.

Can anyone confirm for 16w20a? It looks pretty normal for me, except for very, very many entites on a half decent laptop.

Confirmed in 16w20a. Still exactly the same.

@unknown Thank you! }=)