灵异

只是把图1的328行的两数比较[取需要处理的桶的个数较少的一端]​改成了图2的1140行的两数比较[取需要处理的桶里的元素个数的和较少的一端]​其他没变，时间却慢了许多，如图3，5.69ms变成了6.28ms，3.75ms变成了3.82ms，7.03ms变成了6.87ms，6.26ms变成了6.57ms。​​取数组上的两个数来比较，这个开销应该很小，难道不应该以桶大小和作为负载评估量？以桶个数作为负载大小更科学？导致对两端的选择不准确？​找到了一种低维下比HEM更快的算法，匹配概率很小，只有不到10个匹配订阅，图4，C-BOMP优化后的fRein 0.57ms，比HEM 1.01ms快不少（不过可能是因为在debug模式下HEM测了每种任务的时间多了很多开销，去掉后还是HEM快，而REIN不怎么受这个计算开销的影响）。可惜的是这个桶大小和负载选择优化[谓词粒度负载优化PGWO]和hRein都没什么用。这是低维下的真实事件实验，如果是随机生成的事件，效果还会差不少，可见与值有关，以前做的值倾斜分布生成得不好，以后做值分布实验应该直接测只落入每段区间内的匹配时间！​​9次实验，谓词宽度从0.1到0.9，到0.7时fRein-cbomp报段错误了，到0.3时hRein-cbomp报段错误了。​不知什么原因，比较少见的随机错误。跑完后再单独运行了0.7和0.3的情况，没错了。​BG-Tree上也有类似情况，好像也是C-BOMP优化的锅。非DEBUG模式（debug下某些算法会测量各种细分操作上的时间）下重新跑了遍，fRein cbomp在w0.2，0.4，0.5下都报了段错误，导致最后许多算法只跑了6次实验，图5。​​