Let's say that I have a scoreboard which acts as a timer for armorstands doing something. Every time an armorstand's value in the scoreboard gets to x (for now, let's say x = 20) the armor stand does something, and their scoreboard value is reset.

My question is whether it is more efficient to do
scoreboard players add @e standTimer 1
scoreboard players add @e[type=armorstand] standTimer 1
when increasing the timers.

The rationale for the first one is that if there are less arguments in the selector to parse, the game can just select all entities and be done with it. This seems biased towards the way humans think vs machines, however, as the machine still has to iterate through each entity whereas humans can abstractly say that all entities have had their score incremented by one. The rationale for the second one is that although the game has more arguments to parse, the amount of other entities in the world is so great that not thinning the croud of selected entities is actually more detrimental.

But that's not all. If the amount of armorstands in the world is y, and the total amount of entities is z, at what ratio of y to z does this difference become significant? Because if y:z = 1, all entities in the world must be armorstands, and thus there is no difference. If y:z = 1/2, then half the entities in the world are armorstands, and this probably has some significance. etc. Or it could be based on the actual values of y and z, rather than their ratio.

Finally, how does this change with respect to x? For example, does making x = 1 (so once a tick) change which one is better compared to x = 60?

And if the answer is simply that it really makes no difference, having the selector or not, and running once per tick or once per 100 ticks, best command-writing practice would say to use the selector so your 'code' is more readable.

  • I think I've heard once that the game has premade lists of entities of one type. But it would also be interesting to know how the performance is when checking for other things, like tags, NBT, distance (which uses a different entity list entirely), etc. Also, functions and command blocks might be different as well. For now, I would strongly assume that narrowing down the selection is almost always better. Also, in this specific case you can of course use /schedule. – Fabian Röling Jul 31 '19 at 20:29
  • @FabianRöling The /schedule is a new idea: like having a function recursively schedule itself? I like it, because it definately beats having global fakeplayer timers. However, in this case (let's, in a purely random decision, say the armorstands were turrets and had a reload time of x) you need the scoreboard because each armorstand's reload may be out of sync with the other ones. – Nik3141 Jul 31 '19 at 21:15
  • 1
    Another idea that may be worth testing is to have ONE timer repeatedly count to 20 and give each armor stand a set value, then execute the command from any armor stand with the same score as the timer that tick. To "start" the timer of an armor stand you would simply set it's score to whatever the timer is at in that moment. (I hope this is clear... And I didn't test this for lag, so that's why it isn't an answer) – user232393 Aug 1 '19 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.