为何JavaScript中Array.prototype.filter比桶过滤实现更快？

你的测试结果并不意外，核心问题出在原生方法的底层优化和桶过滤的额外开销上，具体可以拆解成这几点：

• 原生filter是引擎级优化的产物
  JS引擎（比如Chrome的V8）对Array.prototype.filter这类原生方法做了大量底层优化：用编译后的机器码执行循环，跳过了JS层面的解释/编译开销，甚至会根据数组的类型（比如是否是同构的对象数组）做针对性优化。而你的bucketFilter完全是JS层面的逻辑，循环、桶对象的创建/访问、数组合并这些操作都要经过JS解释器，执行成本比原生方法高得多。

• 桶过滤的额外操作抵消了理论优势
  桶方法看似迭代次数少，但多了两步关键的额外开销：

  1. 第一次遍历要把每个元素按indCode分桶，这涉及到哈希计算、桶对象的属性查找与创建；
  2. 第二次遍历要收集符合条件的桶，再把桶内元素合并成结果数组，又多了一次数组拼接或遍历的成本。
     相比之下，filter只需要一次遍历，每个元素只做一次简单的indCode对比，没有多余的中间步骤。

• 数据规模与缓存友好性的影响
  如果你的测试数据规模不大，桶方法的预处理开销会直接盖过它的理论效率优势。另外，filter是顺序遍历数组，内存访问是连续的，CPU缓存命中率更高；而桶方法的元素分散在不同的桶数组里，访问时容易出现缓存 miss，进一步拖慢执行速度。

• 简单过滤条件下，桶方法的优势无法体现
  你的过滤逻辑只是简单的indCode等值对比，这种情况下filter的单次判断成本极低。只有当过滤条件非常复杂（比如需要多次计算才能判断是否符合），或者需要多次基于同一维度过滤时，桶方法的预处理优势才可能显现——但对于这种简单的单次过滤，原生方法的优化完全够用。

内容的提问来源于stack exchange，提问作者Robert Parker