我有一个相当复杂的Javascript应用程序，其主循环每秒调用60次。根据Chrome开发工具中的内存时间轴输出显示，似乎有很多垃圾回收正在进行，这经常影响应用程序的性能。
因此，我正在尝试研究减少垃圾收集器所需工作量的最佳实践。(我在网上找到的大多数信息涉及避免内存泄漏，这是一个略微不同的问题——我的内存被释放了，只是垃圾收集太多了。) 我假设这主要归结于尽可能多地重用对象，但是细节决定成败。
该应用程序以“类”为结构，类似于John Resig的Simple JavaScript Inheritance。
我认为其中一个问题是一些函数可以每秒调用数千次(因为它们在主循环的每个迭代中使用数百次)，也许这些函数中的本地工作变量(字符串、数组等)可能是问题所在。
我知道针对较大或较重对象的对象池技术（我们在一定程度上使用了这种技术），但我正在寻找可以应用于所有情况的技术，特别是与在紧密循环中被频繁调用的函数有关的技术。
有哪些技术可以减少垃圾回收器的工作量？
或许还有一些方法可以用来识别哪些对象被垃圾回收最多？（代码库相当大，因此比较堆快照并没有太大帮助）
许多减少GC运行时的方法在其他大多数情况下都不符合JS惯用法，请在评估我给出建议时，注意上下文。
现代解释器中会发生分配：
new或文字语法[...]、{}创建对象时。(function (...) { ... })时。Object(myNumber)或Number.prototype.toString.call(42)。Array.prototype.slice。arguments反射参数列表时。避免使用以上方法，并在可能的情况下池化和重复使用对象。
具体来说，要寻找机会:
split 或正则表达式匹配进行解析，因为每次操作都需要多个对象分配。这经常发生在查找表和动态DOM节点ID的键入中。例如，lookupTable['foo-' + x] 和 document.getElementById('foo-' + x) 都涉及到字符串拼接的分配。通常可以将键附加到长期存在的对象上，而不是重新连接。根据需要支持的浏览器，您可能可以使用Map来直接将对象用作键。try { op(x) } catch (e) { ... }，而是使用 if (!opCouldFailOn(x)) { op(x); } else { ... }.JSON.stringify，该工具使用内部本机缓冲区来累积内容，而不是分配多个对象。arguments，因为使用它的函数在被调用时必须创建类似数组的对象。我建议使用JSON.stringify来创建发送到网络的消息。解析输入消息使用JSON.parse显然涉及分配，对于大型消息会有大量分配。如果您可以将传入的消息表示为原始数组，则可以节省很多分配。唯一可以构建不分配解析器的内置函数是String.prototype.charCodeAt。但如果只使用它来解析复杂格式，则可能会阅读非常困难。
JSON.parse后的对象分配的空间比消息字符串少（或相等）吗？ - BergiChrome开发者工具有一个非常好的功能，可以追踪内存分配。它被称为内存时间轴。本文描述了一些细节。我想这就是你所说的“锯齿形”吧？对于大多数GC运行时来说，这是正常的行为。分配会继续进行，直到达到使用阈值触发收集。通常在不同的阈值下有不同类型的收集。
request animation frame，animation frame fired和composite layers。我不知道为什么我没有像你那样看到GC Event（这是在最新版本的Chrome和Canary上）。 - UpTheCreek@342342和code relocation info。 - UpTheCreekvar options = {var1: value1, var2: value2, ChangingVariable: value3};
function loopfunc()
{
//do something
}
while(true)
{
$.each(listofthings, loopfunc);
options.ChangingVariable = newvalue;
someOtherFunction(options);
}
将会比这个运行得更快：
while(true)
{
$.each(listofthings, function(){
//do something on the list
});
someOtherFunction({
var1: value1,
var2: value2,
ChangingVariable: newvalue
});
}