D3/SVG：當選擇改變時爲什麼這個代碼更慢？

我有一個組選擇傳遞給這個函數，我使用thisGroup.append（「path」）。blah.blah調用，但它非常慢，可能慢100倍。不能說，因爲有2秒的延遲，但使用如下所示的svg.append幾乎是即時的。誰能告訴我爲什麼？雖然它起作用，但我必須重複我已經爲該組做過的翻譯，並且弄亂了我的svg元素排序。D3/SVG：當選擇改變時爲什麼這個代碼更慢？

for (var i = 0; i < listEdges.length; i++) { 

    var lineSeg = []; 

    //generate coordinates 

    //replace like nodeGroup.append("path") and it become 100 times slower 
    svg.append("path") 
     .attr("d",line(lineSeg)) 
     .attr("stroke", chooseHSL(i)) 
     .style("stroke-opacity", 0.5) 
     .attr("stroke-width", 5) 
     .attr("fill", "none") 
     .attr("transform","translate(580,260)"); 

}

這是我的節點組的聲明方式

var nodeGroup = svg.selectAll("g") 
       .data(listNodes) 
       .enter() 
       .append("g") 
       .attr("id",function(d){ return "Group_" + trimWhitespace(d); }) 
       .attr("transform","translate(580,260)");

以及如何SVG聲明

var svg = d3.select("#container") 
     .append("svg") 
     .attr("id","svgContainer") 

     .attr("viewBox","0 0 1300 610") 
     .attr("perserveAspectRatio","xMinYMid") 

     .attr("width", w + margin.left + margin.right) 
     .attr("height", h + margin.top + margin.bottom) 
     .append("g") 
     .attr("transform", "translate(" + margin.left + "," + margin.top + ")");

來源

2013-06-20 user2483724

你到底想幹什麼？就我個人而言，我認爲它與d3.js混合循環是一種糟糕的形式; d3數據綁定通常是比循環更好的方式。

回到你的問題，當你用svg替換nodeGroup時，你基本上重複循環listNodes.length（listNodes.length x listEdges.length executions而不是listEdges.length）。

也許你應該詳細說明你想要做什麼？

來源

2013-06-20 19:44:28

我有一些非常稀疏的數據，我使用座標發生器放置在一個圓圈內。回想起來，我應該創建一個新的數據集，附加這些座標，然後用新數據創建DOM對象。我繼續前進，所以我必須使用循環。 – user2483724

我明白你的答案，但svg我只是調用循環listEdges次，但與nodeGroup我循環遍歷所有組的循環迭代，因爲nodeGroup代表所有組的選擇。我是否正確地根據你的評論，使用循環沒有利用D3最大的優勢，這是數據與DOM元素的實際綁定，並且在任何有循環的地方，都應該有一種沒有循環的做同樣的事情的方法？ – user2483724

同意你的第一個分析。我發現在做實際的數據綁定之前準備好你的數據集會更好，它大大簡化了你的d3代碼。是否有可能回去修復數據模型？ d3本身提供了一堆非常有用的數組轉換和翻譯工具。 –

D3/SVG：當選擇改變時爲什麼這個代碼更慢？

回答

相關問題