Redundancies in selectors

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 21:52:15 on July 26, 2016 ยท (Permalink)

Suppose I have a command such as /scoreboard players tag @e[type=ArmorStand,name=SomeSpecificArmorStand] add SomeTag {NoGravity:1b}.

The SomeTag tag can be thought of as a property of armor stands named SomeSpecificArmorStand. For all intents and purposes, only such armor stands will possess this tag.

Later on, I type /execute @e[type=ArmorStand,name=SomeSpecificArmorStand,tag=SomeTag] ~ ~ ~ summon Cow.

Does the redundant information specifying type and name in this selector provide any value by making the search quicker, etc., or would I be better off simplifying it to @e[tag=SomeTag] because the type and name are implied by the structure of the system?

Thanks!

Skylinerw ยท 4 points ยท Posted at 00:32:20 on July 27, 2016 ยท (Permalink)*

By just checking for tag, every single entity in existence must have their tags checked. However, it should be a fairly quick operation anyway.

The type parameter is the first parameter processed, so you'd restrict which entities have their tags checked to only armor stands. But that would only be helpful if type is less intensive.

A very quick stress test with 16,384 AreaEffectClouds with no tags and 1 ArmorStand with 1 tag:

  • Base tickrate at 9.6
  • With @e[type=ArmorStand,tag=test], tickrate lowered to 9.4
  • With @e[tag=test], tickrate lowered further to 8.9

Not that much of a difference, and since this is just a very quick test on a whim, probably not conclusive.

With all 16,384 clouds have 100 non-matching tags:

  • Base tickrate at 8.6
  • With @e[type=ArmorStand,tag=test], tickrate lowered to 8.3
  • With @e[tag=test], tickrate lowered further to 7.4

There was more of a significant drop in tickrate when having to traverse a larger mapping. But given that it took 16,000 entities for me to see a "significant" difference, and that having that many in the first place wrecked my tickrate by themselves, I think you'll be fine choosing whichever you feel more comfortable with.

Since the name parameter is processed before tag, including it would be worthwhile if it's more efficient than tag (such as having a huge number of armor stands, and only one has the name, allowing you to check the tags for just that armor stand instead of all of them). I imagine the difference in performance is also negligible.

Any parameters processed after tag would be useless to include if tag is the defining factor. Those would be r/rm, ry/rym/rx/rxm, and dx/dy/dz.

Personally I use type anyway to make absolutely sure to prevent unexpected entities from being included in selection.

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 01:26:08 on July 27, 2016 ยท (Permalink)

Thank you for the analysis. I'm already in the habit of specifying type and name in each selector, so it looks like there's no reason for me to stop.

Your comment did bring to mind another question, though. Why is it that narrowing down every entity based on type is faster than tag? Either way in your scenario, the armor stand is both the only armor stand and the only entity with the tag, so shouldn't it take the same amount of time to search each entity and only grab the one it needs?

Arcensoth ยท 3 points ยท Posted at 03:50:09 on July 27, 2016 ยท (Permalink)*

Checking type is (I assume) a direct lookup, whereas checking tag is a hash lookup. (If I recall correctly, entity scoreboard tags are stored as a hash set.) The hash lookup is basically direct access (in most cases), albeit ever-so-slightly (perhaps negligibly) more expensive than the former.

Searching on both type and tag will result in a hash lookup only for those entities who match the given type, since type is, as /u/Skylinerw said, the first to be processed. Searching purely on tag, on the other hand, will result in a hash lookup for every entity in the world, as nothing is being filtered beforehand.

I can't say for sure if this is the true cause, but I thought it was worth mentioning anyway.

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 03:52:46 on July 27, 2016 ยท (Permalink)

Great information, thank you.

TheEbonySky ยท 2 points ยท Posted at 00:29:27 on July 27, 2016 ยท (Permalink)

It's kind of preference at that point. If you want to make it easier to read and figure out the command itself in the future if you need to @e[type=ArmorStand,tag=SomeTag] may be easier.

I wouldn't worry too much about the search being "quicker" as it can usually be done in one tick regardless unless you're working with like 100s of command blocks or something.