使用d3过渡会导致内存泄漏 [英] Using d3 transitions causes memory leak

问题描述

我在d3.js的帮助下进行了可视化.可视化利用了许多过渡(例如显示/隐藏/移动元素).我注意到CPU负载很高，并且随着时间的推移内存大量增加，一段时间后可视化效果非常慢.

I made a visualization with the help of d3.js. The visualization makes use of a lot of transitions (e.g. showing/hiding/moving elements). I noticed a high CPU load and a large increase in memory over time, making the visualization very slow after a while.

因此，我删除了转场，或将其替换为具有较低帧速率的自制转场功能.不幸的是，删除所有转换不是一种选择，因为这会使可视化效果不那么明显.其余过渡是通过增加/减小圆半径而出现和消失的圆.

I therefore removed transitions, or replaced them with a self-made transition function with a slower frame-rate. Unfortunately, removing all transitions is not an option as this would make the visualization less presentable. The remaining transitions are circles that are appearing and disappearing by increasing/decreasing the circle radius.

似乎仍然存在内存泄漏，大部分发生在chrome中(根据Windows任务管理器，在10分钟内达到20,000K).

Still there seemed to be a memory leak, mostly visible in chrome (20,000K in 10 minutes based on the windows task manager).

因此，我想知道转换本身是否会导致内存泄漏.为了对此进行测试，我制作了一个jsfiddle( http://jsfiddle.net/qdwyoy7r/7/)来看看是否只有一个类似的过渡会显示相同的结果.而且确实如此:在Chrome中运行时，每10分钟内存增加约9,500 K(基于Windows任务管理器).

So I wondered if it could be that the transitions themselves are causing a memory leak. To test this I made a jsfiddle (http://jsfiddle.net/qdwyoy7r/7/) to see whether a single similar transition alone would show the same results. And it does: When run in Chrome, the memory increases around 9,500 K per 10 minutes (based on the windows task manager).

g_svg = d3.select("#visualization")
    .append("svg")
    .attr("width", 300)
    .attr("height", 300);

circle = g_svg.append("circle")
            .attr("cx", 150)
            .attr("cy", 150)
            .attr("r", 0)
            .style("opacity", 0.3)
            .style("fill", "orange");

resize();

function resize(){
    circle.transition()
        .duration(500)
        .attr("r", 100)
        .transition()
        .delay(750)
        .duration(500)
        .attr("r", 0)
    var t = setTimeout(function(){resize()}, 1500);
}

d3转换本身是否可能以某种方式增加了内存使用量?还是我以错误的方式使用d3转换?

我一直在寻找Chrome开发者工具，但它并没有真正帮助我:

I have been looking at the Chrome dev tools but it is not really helping me:

• 时间轴显示了内存使用情况的锯齿模式(但随着时间的推移，该值会降低)
• 堆时间轴显示，大多数(数组)和(编译后的代码)对象的数量都在增加，并且保留了最大的大小.当我展开它们时，它们也包含很多项目，但分析器中显示的项目对我来说没有意义.
• 此外，堆时间轴上的峰值(很可能是由过渡引起的)随着时间的推移越来越高.
• 堆快照的大小并没有增加太多，但是当比较快照之间分配的对象时，我会看到相同的(数组)和(编译后的代码) ...

• the timeline shows the saw-tooth pattern of memory usage (but the value it goes down to increases over time)
• the heap timeline shows that mostly (array) and (compiled code) are increasing in objects and have retained the most size. They also contain a lot of items when I unfold them, but the items shown in the profiler do not make sense to me.
• Also, the spikes on the heap timeline (that are likely caused by the transition), are getting increasingly higher over time.
• the heap snapshots do not increase in size much but when comparing objects allocated between snapshots I see the same (array) and (compiled code)...

推荐答案

这似乎与d3.js无关，但与Windows上的chrome(38)无关.提琴已经运行了一个多小时，并且在Windows任务管理器中测得的内存使用量已从56M变为133M.在另一个浏览器(例如IE 10)上，相同的提琴并没有增加，但是平衡了大约3700万.

This seems not related to d3.js but to chrome (38) on windows. Have been running the fiddle for more than an hour and the memory usage measured in the windows task manager has gone from 56M to 133M. On another browser (for example IE 10) the same fiddle does not go up but balances around 37M.

这篇关于使用d3过渡会导致内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！