单人存档的命令，想到个问题...
举例...49个女人，1个男人，其中有1人戴了帽子，问，有没有女人戴着帽子，那么此时
查看49个女人有没有戴帽子
查看1个男人有没有戴帽子
后面的方法明显比前面的判断得要快
但是我不是程序猿，所以...问下


因为是单人存档，所以@p和@a都是同样的结果，
那么，命令中使用@p(@a)的检测/运行速度会比@a(@p)快，或者说占用内存/CPU相对较少...
有这种可能吗...如果有的话...
@a

@p

哪个更快/更省...



类似的问题...
存档下有一个AEC，只有AEC有a标签，那么
@e[tag=a]

@e[tag=a,type="AEC"]

哪个更快/更省...


同样的姿势...
存档下有一个带a标签的AEC，只有这个AEC有a标签。游戏下存在多个AEC，那么
@e[tag=a]

@e[tag=a,type="AEC"]

@e[type="AEC",tag=a]  (排序...如果会影响到的话)
哪个更快/更省...



因为突然想到如果有3000 AEC 其中1个a标签的AEC
那么如果@e[type="AEC",tag=a]，选择器是先筛选出type，然后才在列表中在筛选出tag=a
感觉就会比@e[tag=a,type="AEC"]，先找a，再找type来得快
而如果单纯@e[tag=a]的话又会从所有存在的实体中开始筛选

最近在写数据包，命令就算写长点也没关系，只希望可以让运行负担尽量减少，或检测速度加快...

我个人认为@a更省

【刚才手机打了几百字，一个返回就没了...】
这问题挺不错的，那么我就认真一点回答，附上详细点的解释，但这会比较多字。

首先简单的回答一下：
1. 少目标比多目标好
2. 选择器参数顺序不重要
3. 多余的检测没用
（后面这两我看了一下代码）

原因：
1. 命令进阶里的目标选择器部分其实有简述过选择器的运行原理。
   选择器会首先筛选出符合要求的所有目标，然后对那些目标以世界、距离进行排序（如果是1.13的sort=arbitrary则不用排序）   ，然后在根据数量限制参数选出目标（如果需要）。
   简单来说呢，1.12的或之前，如果选择到（不计算c参数的影响）的实体越多，就越卡，因为需要对大量实体进行排序。
   1.13使用sort=arbitrary的话，在选择器一方面来说，目标多少是没太大分别的。（目标少自然快一点，但那分别应该是不能察觉的）
   
   然而，命令不止包括选择器，我们还得考虑选择器在命令里的运行原理。
   举个例子，clear一堆玩家其实是对每个玩家逐个进行clear。那么，目标越多命令执行次数越多，自然就卡了。
   
   所以总括而言，即使1.13选择器在选择很多目标的时候效率不错，我们也应该选择少点的目标，因为你还得执行命令。

2、3. 选择器参数顺序不重要，并且多余检测也没用。
      各位有兴趣的话可以去看看mcp和google quava 的 com.google.common.base.Predicates
      基本上mc会依照自己的顺序去对那堆条件进行“排序”，其实就是写死了那顺序...
      所以参数顺序基本上是没分别的。
      
      至于多余的检测一方面呢，那就是和 Predicates 里的实现相关了。
      如果Predicates是把目标逐个predicate的filter的话，参数多少或许会有分别。
      但人家是list里的逐个item去逐个predicate给apply...也就是说多了参数只会更卡（如果你能察觉的话）

差点忘了说，@a和@p应该差不多
只有@s是最省的

那么 如果使用marker的UUID代替它的@e[tag=""]呢