3

背景：

所以我需要对很多字符串进行排序。实际上是字符串数组，但这不是重点。不是我需要实现自己的排序器功能，如链接问题中所述。性能对我来说非常重要。jFriend00 非常有帮助地建议我使用String.prototype.localeCompare. 我正在排序的数组有 100K+ 个元素，因此性能非常重要。在MDN 文档中.localeCompare，在 下Performance，它说：

在比较大量字符串时，例如对大型数组进行排序时，最好创建一个 Intl.Collat​​or 对象并使用其 compare 属性提供的函数。

使用它似乎很简单，并且 jFriend 函数的实现如下所示在功能上似乎是等效的：

data = (function(arrE2){
  var nIC = new Intl.Collator,
      cmp = nIC.compare.bind(nIC);

  return arrE2.concat().sort(function(a, b) {
      var comp, i;
      for (i = 0; i < Math.min(a.length, b.length); i++) {
          if ((comp = cmp(a[i], b[i])) !== 0) return comp;
      } 
      return (a.length > b.length) - (a.length < b.length); 
  });
})(data);

（如果它与 jFriend 的解决方案不同，请纠正我。）

但是，我不清楚这是否会产生任何显着优越的性能，如果是，那么如何。MDN 当然可以更好地解释，因为Intl.Collat​​or的链接页面甚至没有提到“性能”。所以我只好留给我自己的设备..我是一个 n00b，所以我的直觉是毫无价值的，但我能想到的提高性能的唯一方法是，如果规范的替代方案需要将整个语言环境加载到每个单独的比较都会重新分配内存，而这会保留分配的内存以将区域设置数据存储在对象中。

我的问题是：

  • 两者在行为上是否相同？
  • 我的新版本在性能上是否更出色，如果是，是否显着？
4

1 回答 1

4

我遇到了类似的问题，发现这个 jsperf真的很有用。

底线：是的，Intl.Collator几乎是a.localeCompare(b).

于 2015-05-27T19:34:25.873 回答