JavaScript性能故事：選擇可視化方法

　　不完美的堆造就完美的圖形

　　我寫的工具能提供多少價值，將由其快速診斷內存配置文件問題的能力的大小決定�？紤]到我可以利用直覺工程 來增強可視化的方法，我提出了三個成功的標準:

　　能夠很容易創建基線。 這樣用戶就可以在不同的堆配置文件或時間樣本之間輕而易舉的看出差異。

　　能夠快速有效地傳達問題。

　　能夠有效地顯示許多節點。 許多，許多，許多。

　　為了有效地創建基線，我們需要一些能夠一目了然就能表示很多相關數據的東西。 我用來表示節點的兩種工具是大小和顏色。 通過大小繪制節點，能夠快速的將占用內存大的應用程序給高亮顯示出來。 類似地，通過顏色會直接點也能夠一目了然的分析堆狀態。

　　有了這個總體思路,如何傳達問題這個難題也就迎刃而解了。結合Chrome堆配置文件的輸出和我自己的經驗，我知道節點自身大小和保留大小至關重要。 我也知道我需要找出一些代表保留者的方法，因為它們在解決內存問題方面發揮了關鍵作用。

　　第一個猜測？力導向圖

　　需要尋找出一個能夠既能夠單獨顯示實體格式大小的和顏色的，又能夠指示出它們之間的關系，因此我想到了力導向圖。

(圖片來源：Martin Grandjean)

　　力導向圖非常棒！為了體現通信的重要性,它們會檢查所有的box——有效地表示不同大小的節點，顏色，它們顯示節點之間的關系。D3甚至提供了一個強制布局模塊，使得它可以很容易地實現其中一個sucker。

　　不幸的是，它們沒有達到性能的要求。強制布局的計算成本很高。大多數瀏覽器需要幾分鐘的時間來布局數千個節點。 此外，當它們變大時，看上去也會變得很擁擠。

　　帶有20萬個節點的力導向圖(圖片來源：graphmap.net)

　　如果我的工具需要花費很長時間來布置堆，或者如果很難獲得關于單個節點的相關診斷信息，那么它也不會比手工解析數據更有用。 最后，我決定pass力導向圖這個選項。

　　要不試試圓形圖？

　　對于力導向圖，它們使用了圓形來代表節點，這個做法我的確是很喜歡。從視覺的角度來說，還是很有吸引力的，也比較容易理解。 當然，如果它畫圖的代價不是那么高就好了！

　　在渲染force layout的過程中，大多數的難題都是來自于需要繪制出節點之間的關聯性。如果我能找到一個類似的布局，但沒有明確地繪制邊緣，那么我就可以渲染所有需要的節點。

　　進入圓包。

　　看一下圓形圖的效果：

　　(圖片來源：Mike Bostock 和 Jeff Heer)

　　我在這里看到了一些潛在的優勢 - 它具有力導向圖的很多優點 - 圓形節點，彩色節點和相對大小的一目了然 - 但是卻不像力導向圖那樣需要去計算對象之間的關聯。

　　當然我也看到了一些缺點:

　　1.對于深度嵌套的層次結構，它的效率很低。

　　2.很難體現出節點之間的非層次關系。

　　為了解決第一個問題，我決定盡可能地把數據拉平。請記住，內存通常表示為圖形，有時也會表示為支配樹，默認情況下不分層，但是如果需要，它也可以按類型或其他限定進行分組。

　　接下來說一下第二個問題。我喜歡圓形布局，我認為需要展示給用戶的唯一指示是文本列表，以及節點上的數字。往往只會在確定問題之后出現，才能感受到保留者的價值，所以我決定簡化最初的可視化，只包括那些有問題的元素。

　　榮譽獎：Treemap

　　您可能會想，既然大型數據集的性能要求如此之高，為什么不使用Treemap呢?

(圖片來源：MDN)

　　我來講一下為什么當初我沒有選擇Treemap的真實原因吧:

　　Treemaps看起來并不像圓形布局那樣具有視覺吸引力；

　　它太簡單了！與其他圖形類型相比，構建一個樹形圖所需要付出的計算代價太小了；

　　Firefox已經做到了。

　　我已經采用了圓形布局作為我的可視化方法，下面簡述一下幾個額外的原因。

　　我不關心超出節點類型的層次結構。 樹圖可以快速顯示層次結構中的重量，但對于一個相對平坦的樹，要繪制出輪廓就更加困難了。

　　從某種意義上說，圓形布局通常認為比等同的樹形圖更容易消耗視覺效果。 我相信他們講到了一個重點- 節點之間的空間使得它更容易被識別組之間的模式。

　　所以，問題就解決了！ 我決定使用圓形布局，并將其視為可視化內存堆的一個很好的選擇。