这是Xpath评估中的Chrome错误

Question

打开此页面：http://sunnah.com/abudawud/2

在控制台中运行这个简单的xpath搜索查询。然后浏览器选项卡崩溃

for(var k=0, kl=2000; k < kl; k++){
    console.log(k);
    var xpathResult = document.evaluate("//div[@class='hello']", document, null, XPathResult.ANY_TYPE, null);
}

在Macbook Pro，OSX 10.10.5上的Chrome版本46.0.2490.80（64位）上

不幸的是，我必须在这个页面上运行xpath几千次才能搜索不同的元素。所以我不能做那么多的评价电话。

崩溃取决于xpath术语。对于某些术语，它会崩溃，而对于其他一些术语则不会崩溃。

它在同一计数上始终失败，因此它让我觉得它不是计时问题或垃圾收集问题。

我没有收到任何错误代码，因此我不确定在哪里查看。

更新 经过进一步调查后，我们认为这是一个合法的Chrome错误，或者至少不是很好的释放内存的方法。如果您的xpath以/或//开头，那么搜索上下文将扩展到所有DOM，并且由于某种原因，chrome会将DOM或其​​他一些中间对象保留在内存中。如果xpath确实以相对路径（div / p）开头，并且搜索范围（第二个参数）设置为DOM的部分，则内存消耗更加合理并且没有崩溃。感谢@JLRishe提供了一些非常有助于得出这个结论的提示。

UPDATE2 我提出了铬的错误。但几个月之后，他们拒绝了这个错误。我设法暂时解决它。

Answer 1

如果我在该页面上运行您的代码并观看任务管理器，我可以看到Chrome的工作集增加到大约3.3 GB，然后在大约1300次迭代后最终崩溃。

每个XPath查询都会导致Chrome为结果和获取它们所涉及的任何操作分配内存，但似乎它没有释放任何已分配的内存，因为您没有释放对该线程的控制权。

我发现工作集的水平为1.65 GB，如果我这样做，操作就会完成而不会崩溃：

var k = 0;
var intv = setInterval(function () {
    console.log(k);
    var xpathResult = document.evaluate("//div[@class='hello']", document, null, XPathResult.ANY_TYPE, null);
    k += 1;
    if (k >= 2000) {
        clearInterval(intv);
    }
}, 0);

所以类似的东西可能是一种可能的解决方案。

这仍然使用相当多的系统资源，甚至不包括您在操作过程中可能存储的任何值。我鼓励您寻求一种不需要运行相当多XPath查询的更智能的方法。