V8 JavaScript对象与二叉树

有没有更快的方式来searchJavaScript数据（特别是在V8通过node.js ，但没有C / C + +模块）比使用JavaScript Object ？

这可能已经过时了，但是它表明每个属性都会dynamic生成一个新的类。这让我想知道二叉树的实现是否会更快，但是这似乎并不是这样。

二叉树的实现不是很好的平衡，所以平衡可能会变得更好（只有前26个值大致用手来平衡）。

有没有人有一个想法，为什么或如何改善？另一个说明：dynamic类的概念是否意味着实际上有约26万个属性（在第二个链接的jsperf基准testing中），并且随后在内存中保留了dynamic类定义链？

V8使用“地图”的概念来描述对象中数据的布局。

这些映射可以是“快速映射”，它指定从可以find特定属性的对象开始处的固定偏移，或者它们可以是“字典映射”，其使用散列表来提供查找机制。

每个对象都有一个指向描述它的地图的指针。

一般来说，对象以快速地图开始。将属性添加到具有快速映射的对象时，映射将转换为描述对象内新属性位置的新映射。如果需要的话，该对象被重新分配足够的空间用于新的数据项目，并且对象的地图指针被设置为新的地图。

旧的地图保留了它的转换logging，包括一个指向新地图的指针和一个附加引起地图转换的属性的描述。

如果另一个具有旧地图的对象获得相同的属性（这是非常普遍的，因为相同types的对象倾向于以相同的方式使用），该对象将只使用新地图 – V8不创build新的地图在这种情况下。

但是，一旦属性的数量超过了一定的阈值（实际上，当前的度量是使用的存储空间，而不是实际的属性数量），对象更改为使用字典映射。此时使用散列表重写对象。一般来说，它不会经历更多的地图转换 – 添加的任何更多的属性将只进入散列表。

快速映射允许V8生成优化的代码（使用曲轴），其中对象内的属性偏移被硬编码到机器代码中。这使得它可以做到这一点非常快 – 它避免了查找的需要。

显然，生成的机器代码依赖于映射 – 如果对象的数据布局发生变化，代码必须丢弃并在必要时重新优化。 V8有一个types分析机制，它收集关于执行未优化代码期间各种对象的types的信息。它不会触发代码的优化，直到满足一定的稳定性约束 – 其中之一是函数中使用的对象的映射不经常变化。

下面是这个东西如何工作的更详细的描述。

这里有一个video，V8的主要开发者之一描述了地图转换等等。

对于您的特定testing用例，我认为在准备循环中添加属性时会经历几百次映射转换，然后最终转换为基于字典的对象。这当然不会通过26万。

关于你的二叉树问题：一个正确大小的散列表（有一个合理的散列函数和大量的对象）将总是胜过二叉树的用例，你只是在search，因为你的testing代码似乎（所有的插入都是在设置阶段完成的）。