Paper: "armor-stands-ticks: false" does not boost the performance anymore

Created on 30 Mar 2019  路  9Comments  路  Source: PaperMC/Paper

Exhibiting the armorstand ticks has no more performance effect.
The feature itself does something with the armorstands, but no longer contributes to the actual goal, the performance improvement. The evidence that something happens at all are not falling armorstands.

I did under the same setup with only one player over the same time span measurements. On version 1.13.2 597 and 465 there is no measurable difference between activated and deactivated armor-stands-ticks.
armor-stands-tick: false -> https://imgur.com/a/SDEVW5X
armor-stands-tick: true -> https://imgur.com/a/RyArR57

If you test the same on version 1.12.2 you get the same results on version 1611 as on version 1.13.2.
But if you use version 1589 you get an incredible performance boost:
armor-stands-tick: true ->https://imgur.com/a/2aFrMhP
armor-stands-tick: false -> https://imgur.com/a/k6Oprlh

In version 1591 the following was implemented: "Persist ArmorStand canTick API value across restarts".
What was changed in the update that armorstands perform so much worse afterwards? Is it possible to change that again for version 1.13.2? The awesome performance boost of many armorstands would be just amazing! The version 1.13.2 runs shitty in contrast to the 1.12.2, thanks to Mojang's policy to optimize stuff only in version 1.14. So this possibility would save me xD.

input wanted we must go deeper

Most helpful comment

I went ahead and tested this issue today and it's definitely not an issue - it's a feature! and I fully understand why you say that the "Persist CanTick across reboots" feature lead to the reduced performance.

The commit you're mentioning made it so that the value is saved to the armor stand itself - this means that if you change the toggle in your paper config, the value will not change for armor stands that were spawned / created while the value in the config was something else.

You can easily test this by making a new world, leaving everything on default, and spawning in 1,000 armor stands. In my case, 7 TPS. Using the entity data commands on an armor stand, I can see that it has "Paper.CanTick: 1b" meaning it's ticking - as expected.

Now shut the server down and change the value in the config. Start it up again. Still 7 tps. Still "Paper.CanTick: 1b". Nothing changed!

Repeat this test but with the value disabled in the paper config. All new armor stands will have "Paper.CanTick: 0b" and even with 1,000 armor stands, a solid 20 tps.

If you want this to apply retroactively on your existing world - you can either use a plugin to set this value to false on armor stands using the respective API when they're loaded, or use a looping command block to set the value to false on armor stands occasionally. API is of course preferable.

All 9 comments

My presented tests are of course very inaccurate, now that I'm thinking about them more closely.
The problem is reproducible more easily: Just spawn 1000 armorstands in one place and look at the timings. If you now turn the armor-stand-ticks on and off you won't see any changes in the timings with the latest version of Paper 1.12.2 and 1.13.2. With Paper 1.12.2 - 1589 and armor-stands-ticks = false you can observe an extreme performance boost.
What is the reason for this and is it possible to improve it in the current versions?

This is still ongoing.

Does anyone have a world they can upload or link to which heavily uses armour stands? The armour stands should be moving around and getting updated and all that. This would greatly help testing this and any performance fixes.

I went ahead and tested this issue today and it's definitely not an issue - it's a feature! and I fully understand why you say that the "Persist CanTick across reboots" feature lead to the reduced performance.

The commit you're mentioning made it so that the value is saved to the armor stand itself - this means that if you change the toggle in your paper config, the value will not change for armor stands that were spawned / created while the value in the config was something else.

You can easily test this by making a new world, leaving everything on default, and spawning in 1,000 armor stands. In my case, 7 TPS. Using the entity data commands on an armor stand, I can see that it has "Paper.CanTick: 1b" meaning it's ticking - as expected.

Now shut the server down and change the value in the config. Start it up again. Still 7 tps. Still "Paper.CanTick: 1b". Nothing changed!

Repeat this test but with the value disabled in the paper config. All new armor stands will have "Paper.CanTick: 0b" and even with 1,000 armor stands, a solid 20 tps.

If you want this to apply retroactively on your existing world - you can either use a plugin to set this value to false on armor stands using the respective API when they're loaded, or use a looping command block to set the value to false on armor stands occasionally. API is of course preferable.

If this is true, we probably want the config setting to apply to all armorstands the API does not touch. Perhaps only writing the saved value if it is manually set by a plugin.
That way you can still turn most of them on or off and then plugins that rely on a specific state can override individual ones. This is still relatively opaque to users but certainly less than now, if true.

Thank you very much for sharing your research @Puremin0rez ! That's just awesome! By the small operation we managed to reduce the required performance for the 3000-3500 loaded armorstands from 40-50% to 1-3% in the timings. The trick is profitable for everyone who has more than 800 armorstands loaded at the same time, from that point on it starts to hurt on average! I can only recommend to exclude armorstands with base plate from the operation so that they still fall down!

We've noticed this as well, but due to all the damage we wound up applying a patch to totally disregard the saved CanTick. The functionality isn't useful for us anyway, so we can live without it.

The latest versions of 1.13.2 and 1.14.4 include the changes suggested by @Puremin0rez and implemented by @kickash32. Thanks to both of them.

The changes are implemented and are working perfectly, many thanks! Thanks to the API, everyone can exclude what they want, for example default armor stands with base plate. I think it's time to close the ticket :)

Was this page helpful?
0 / 5 - 0 ratings