JavaScript地图对象是否已编入索引以优化map.get？

Question

在V8幕后，JavaScript-Map-object的键是以某种方式编制索引的，以优化map.get方法？或者map.get()只是循环遍历整个地图，直到它发现一个关键匹配？

我对map.get对500,000多个键/值对的大型映射的效率感兴趣。我有这么多映射，我只想缓存在RAM中，而不是查询已经为快速值检索索引密钥的数据库。在我看来，如果Map对象的键以某种方式在幕后编入索引，那么查询RAM而不是数据库会更快。

摘要：

function randomUniqueThing()
{
   // returns (magically) a unique random: 
   //  string, number, function, array or object.
}
var objMap = new Map();
var count = 0;
var thing1,thing2;
while(count < 500000)
{
    thing1 = randomUniqueThing();
    thing2 = randomUniqueThing();
    objMap.set(thing1, thing2);
    count++;
}
var lastValue = objMap.get(thing1); // Will getting this last
                                    // thing's value take longer
                                    // than getting other values?

Answer 1

是的，正如您对这种数据类型所期望的那样，Map确实利用了一个哈希表。实际上，Map是Object的子类。

来源证明：

与往常一样，证据在源头：

摘自V8源文件src/objects.h class JSMap：

// The JSMap describes EcmaScript Harmony maps
class JSMap : public JSCollection {
 public:
  DECLARE_CAST(JSMap)

  static void Initialize(Handle<JSMap> map, Isolate* isolate);
  static void Clear(Handle<JSMap> map);

  // Dispatched behavior.
  DECLARE_PRINTER(JSMap)
  DECLARE_VERIFIER(JSMap)

 private:
  DISALLOW_IMPLICIT_CONSTRUCTORS(JSMap);
};

我们可以看到，JSMap扩展了JSCollection。

现在，如果我们看一下JSCollection的声明：

摘自V8源文件src/objects.h class JSCollection：

class JSCollection : public JSObject {
 public:
  // [table]: the backing hash table
  DECL_ACCESSORS(table, Object)

  static const int kTableOffset = JSObject::kHeaderSize;
  static const int kSize = kTableOffset + kPointerSize;

 private:
  DISALLOW_IMPLICIT_CONSTRUCTORS(JSCollection);
};

在这里我们可以看到它使用了一个哈希表，并附有一个很好的注释来澄清它。正如我之前提到的，这反过来扩展了常规JSObject。

关于哈希表是仅引用对象属性而不引用get方法，存在一些问题。我们可以从源代码到Map.prototype.get，正在使用哈希映射。

摘自V8源文件src/js/collection.js MapGet：

function MapGet(key) {
  if (!IS_MAP(this)) {
    throw MakeTypeError(kIncompatibleMethodReceiver,
                        'Map.prototype.get', this);
  }
  var table = %_JSCollectionGetTable(this);
  var numBuckets = ORDERED_HASH_TABLE_BUCKET_COUNT(table);
  var hash = GetExistingHash(key);
  if (IS_UNDEFINED(hash)) return UNDEFINED;
  var entry = MapFindEntry(table, numBuckets, key, hash);
  if (entry === NOT_FOUND) return UNDEFINED;
  return ORDERED_HASH_MAP_VALUE_AT(table, entry, numBuckets);
}

摘自V8源文件src/js/collection.js MapFindEntry：

function MapFindEntry(table, numBuckets, key, hash) {
  var entry = HashToEntry(table, hash, numBuckets);
  if (entry === NOT_FOUND) return entry;
  var candidate = ORDERED_HASH_MAP_KEY_AT(table, entry, numBuckets);
  if (key === candidate) return entry;
  var keyIsNaN = NumberIsNaN(key);
  while (true) {
    if (keyIsNaN && NumberIsNaN(candidate)) {
      return entry;
    }
    entry = ORDERED_HASH_MAP_CHAIN_AT(table, entry, numBuckets);
    if (entry === NOT_FOUND) return entry;
    candidate = ORDERED_HASH_MAP_KEY_AT(table, entry, numBuckets);
    if (key === candidate) return entry;
  }
  return NOT_FOUND;
}

通过基准测试证明：

还有另一种方法可以测试它是否使用哈希映射。制作许多条目，并测试最长和最短的查找时间。像这样：

'use strict';

let m = new Map();
let a = [];

for (let i = 0; i < 10000000; i++) {
    let o = {};
    m.set(o, i);
    a.push(o);
}

let lookupLongest = null;
let lookupShortest = null;

a.forEach(function(item) {
    let dummy;
    let before = Date.now();
    dummy = m.get(item);
    let after = Date.now();
    let diff = after - before;
    if (diff > lookupLongest || lookupLongest === null) {
        lookupLongest = diff;
    }
    if (diff < lookupShortest || lookupShortest === null) {
        lookupShortest = diff;
    }
});
console.log('Longest Lookup Time:', lookupLongest);
console.log('Shortest Lookup Time:', lookupShortest);

几秒钟后，我得到以下输出：

$ node test.js
Longest Lookup Time: 1
Shortest Lookup Time: 0

如果在每个条目中循环，那么这样的关闭查找时间肯定是不可能的。