在 Javascript 中：内存分配与大对象操作答案

【问题标题】：In Javascript: memory allocation versus large object manipulation在 Javascript 中：内存分配与大对象操作
【发布时间】：2012-08-08 11:43:45
【问题描述】：

我有一个 JavaScript 模块来维护和操作大量数据。我有四个大型结构——每个基本上都是数组对象的对象。而且里面有很多数据。当用户执行删除或更新某些操作时，我需要遍历这些结构中的每一个并可靠地修改结构以反映更改。在某些结构中，根据用户操作，我不知道我需要更改哪个“叶子”对象，因此我必须遍历所有对象，等等。

在发生更改时操作这些大型结构的另一种方法是将它们清空并从原始数据中重建它们。这就是我的问题：

从性能的角度来看，在 Javascript 中，循环和修改现有（大型）数据结构还是简单地从原始数据重建结构会更优化？

我确定答案可能是“视情况而定”，但 a) 假设有大量数据； b) 假设该数据经常更改。

【问题讨论】：

好问题。我猜想在大型结构中操作每个节点的性能会低于重建，因为你正在做一个 get 和 set 而不是一个 set，但是如果你只是在一个巨大的结构中改变一个东西，那么重建将会是性能较差。但我只是推测-我没有证据！ :)
这都是假设性的，但我的方法可能是提前做好准备，将这些大对象分解为较小对象和数组的集合。因此有望减轻不确定性和深入检查的需要。
听起来像是计划不周的数据结构。如果您更详细地描述您心中的目标，人们可能会帮助您更好地组织结构。
即使循环，也就是 O(n)，对于合理的 n/C 组合来说非常快； Big-O 只是一个界限.. 是否存在性能问题？ 如果没有，请不要担心性能。 尽管如建议的那样，清理模型是可能的..

标签： javascript memory

【解决方案1】：

对不起，我知道您并不期待这个答案，但“这取决于”:-) 但是，我认为我可以给您的最佳答案是当我遇到完全相同的问题时我所做的：我实现了自己简单的测试台来测量对巨大的超级对象执行某些操作所花费的时间：我得到了不同级别信息熵的平均时间测量结果，结果最快的解决方案是从原始结构重建结构。我在 Internet Explorer 中特别注意到了这一点。也许 IE 在循环中表现不佳（我在推测）并且遍历超级对象比重建它要慢得多。因此，它可能不仅取决于超对象的结构，还取决于 javascript 引擎。

但是，这又是我的情况。我建议自己实现一个简单的测试平台：它不会花费太多时间，但最终会让你得到很好的结果；-)

编辑：

作为附录，我想知道在服务器端构建超级对象然后将其作为 JSON 对象发送回浏览器是否会改善结果。我不知道在你的情况下是否可能。您可以实现某种 AJAX 可访问的 PHP 脚本来接收命令（例如插入、删除、重命名等），然后它将新的 JSON 对象发送回浏览器，浏览器只会解析该对象（可能快速操作？？）

【讨论】：

IE 几乎不以 JS 性能而闻名。在我见过的大多数 [micro] 基准测试中，它有时是最后一个，有时有几个因素。但是，我认为这个答案的重要一点是 implement .. [a] testbench to measure（所以 +1）.. 因为它会因正在做的事情、压力的资源以及在什么实施..
谢谢@pst。事实上，看到一段漂亮的代码在所有浏览器中都运行良好，但在 IE 中运行，这是非常令人沮丧的。我说令人沮丧，因为你知道，客户经常坚持使用 IE 并且无法理解它。我最终骗了他们，说他们应该安装 Chrome/FF，因为它们需要“平台”才能让应用程序运行 ¬¬ 有趣但又令人沮丧。

【解决方案2】：

我不确定它是否适用于此，但它让我想起了 blog post from wingolog.org 关于 v8 的实现：

Ed.: Vyacheslav Egorov 写信说 V8 保留的是实际上是函数源，而不是 AST。它根据需要重新解析。说得通。我记得 Lars Bak 在视频中说来源是最紧凑的 IR，也许确实如此。

所以基本上，当 v8 编译 JavaScript 时，它只保留原始数据（源代码），因为在这种情况下，内存占用是最影响性能的因素。

【讨论】：