-1

我正在尝试在 JavaScript 中构建一个包含关联数组元素的大型数组（22,000 个元素）。我是否需要担心关于内存使用的索引长度？

换句话说，以下哪个选项可以节省内存？或者它们在内存消耗方面是否相同？

选项1：

  var student = new Array(); 
  for (i=0; i<22000; i++)
   student[i] = {
   "studentName": token[0],
   "studentMarks": token[1],
   "studentDOB": token[2]
   };

选项 2：

  var student = new Array(); 
  for (i=0; i<22000; i++)
   student[i] = {
   "n": token[0],
   "m": token[1],
   "d": token[2]
   };

我试图在 Google Chrome DevTools 上对此进行测试，但做出决定的数字不一致。我最好的猜测是，因为数组索引重复，浏览器可以通过不为每个学生[i]重复它们来优化内存使用，但这只是一个猜测。

编辑： 为了澄清，问题如下：一个包含许多小关联数组的大数组。在内存需求方面，使用长索引或短索引是否重要。

编辑2： 评论中建议的3N数组方法和@Joseph Myers所指的是创建一个数组'var student = []'，大小为3 * 22000，然后使用student [0]作为名字，学生[1] 用于标记，学生 [2] 用于 DOB 等。

谢谢。

4

2 回答 2

3

差别不大，所以答案是否定的。这种事情，甚至连微优化都算不上。遇到这种困境时，您应该始终选择最易读的解决方案。从您的第二种选择中维护代码的成本超过了您可以从中获得的任何（如果有的话）性能提升。

你应该做的是使用文字来创建一个数组。

[]而不是new Array(). （只是一个旁注）

解决您的问题的更好方法可能是找到一种方法来部分加载数据，实现某种分页（我假设您没有在客户端上进行大量计算）。

于 2013-06-26T03:15:22.227 回答
1

关联数组的计算成本的主要分析与随着存储元素数量的增加而降低的性能有关，但是随着密钥长度的增加，有一些关于性能损失的结果可用。

在Sedgewick的 C 语言算法中，注意到对于一些基于密钥的存储系统，搜索成本不会随着密钥长度的增长而增长，而对于另一些系统，它会增长。所有基于比较的搜索方法都依赖于密钥长度——如果两个密钥仅在最右边的位上有所不同，那么比较它们所需的时间与它们的长度成正比。基于散列的方法总是需要与密钥长度成比例的时间（以便计算散列函数）。

当然，密钥会占用原始代码中的存储空间和/或至少暂时占用脚本执行中的存储空间。

用于 JavaScript 的存储类型可能因不同的浏览器而异，但在资源受限的环境中，使用较小的键将具有优势，例如优势仍然太小而无法注意到，但在某些情况下，优势肯定是值得。

PS 我的图书馆刚刚收到了我在 12 月订购的关于最新计算算法的两本新书，我明天可以检查它们，看看是否有任何关于键长度影响关联数组/JS 对象性能的新结果。

更新：像studentNameNexus 7 上的键需要 2% 的时间，iPhone 5 上的时间需要 4%。这对我来说可以忽略不计。我平均 500 次创建一个 30,000 元素的数组，每个元素包含一个 object{ a: i, b: 6, c: 'seven' }与 500 次使用 object 的运行{ studentName: i, studentMarks: 6, studentDOB: 'seven' }。在台式计算机上，程序仍然运行得如此之快，以至于处理器的频率/中断次数等会产生不同的结果，整个程序几乎立即完成。每隔几次运行一次，大密钥大小实际上会更快（因为测试环境中的其他变化对结果的影响超过 2-4%，因为 JavaScript 计时器基于时钟时间而不是 CPU 时间。）您可以自己尝试在这里：http ://dropoff.us/private/1372219707-1-test-small-objects-key-size.html

您的3N数组方法（对第一个对象的内容使用 array[0]、array[1] 和 array[2]；对第二个对象使用 array[3]、array[4] 和 array[5]，等等.) 比任何对象方法都快得多。它在桌面上比小对象方法快 5 倍，比大对象方法快 5 倍加 2-4%，在 Nexus 7 上快 11 倍。

于 2013-06-26T03:37:48.080 回答