Hacker News Reader

Comment by taeric | Hacker News Reader

Sadly, I mostly dislike tree maps. At large, I never actually see the tree structure that they are supposedly helping me see. Well done ones can be pretty, but that is true of basically every visualization.

The worst is when someone shows a tree map like viewing of something like a CPU, but that is not at all how those are necessarily logically connected. Such that many go for an odd mix of tree and heat maps, but then fail to actually show anything useful that a simple ordered list couldn't also show.

View on HN

Personal favorite, visualizing used disk space in order to find large directories that can be deleted. I use QDirStat on Linux and WizTree on Windows.

Showing CPU performance of an application is a pretty neat use case of one type of treemaps too, typically called flamegraphs too, but in reality I think they're just up-side down treemaps :)

yeah i have a deep infatuation with it too. i like disk inventory x and the visualization really works for me. i wanted to visualize my financial accounts and how much each one had etc (rather than seeing it in numbers) so i built a script to generate files in bytes representing the amount of money in each account and then build a temporary directory and then load it in disk inventory x. really interesting.

i ended up building my own library in react to render various things like what i spend my time in throughout the day (using rescuetime api) to gain better insights into my day. really neat stuff!

Kinda love that creative use of disk inventory x. Kudos.

sounds pretty cool; willing to publish your libs?

I did something similar a little bit more directly in my finance visualization app. (It's written in F# and there was a .NET Treemap control I could easily use. At the moment it mostly relies on Mint [Intuit] CSV exports, but the benefit to that is that I could treemap based on the Mint categorization tree.)

Flamegraphs aren't treemaps because they don't fill the entire viewport. They're really just call stacks on a timeline.

Treemaps can be used though, KCachegrind for example uses treemaps much like KDirStat/WinDirStat: https://blog.equanimity.nl/images/qcachegrind.png

Flamegraphs are (usually) not a timeline.

> The x-axis spans the sample population. It does not show the passing of time from left to right, as most graphs do. The left to right ordering has no meaning (it's sorted alphabetically to maximize frame merging).

https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

Yeah, I tend to prefer sunburst charts for visualizing disk space (I wish there were one for process size, too). I first saw this in kfilelight and on mac I ended up purchasing "DaisyDisk". The hierarchy is clearer and big outliers still stand out.

Unfortunately, most sunburst charts for disk space fails to properly scale things so things that looks like they are larger, are actually smaller. I don't know if this is the case for DaisyDisk, but surely something to watch out for.

> This is a flame graph (which is an adjacency diagram with an inverted icicle layout), using polar coordinates. It is very pretty, and as someone said "it always wows". Sunbursts are the new pie chart. Deeper slices exaggerate their size, and look visually larger. The smaller-looking slice 2 in this image represents 27.7 Mbytes, whereas the larger-looking slice 1 is 25.6 Mbytes. This visualization is actually showing that slice 1 is smaller than slice 2, although I bet most people would think it was the other way around! The problem is that to understand this correctly requires the comparison of angles, instead of lengths or areas, which has been evaluated as a more difficult perceptive task.

https://www.brendangregg.com/blog/2017-02-06/flamegraphs-vs-...

Yes exactly!! It took me a bit too long to realize that treemaps visualize the same structure as flame graphs, and I like flame graphs better

Also, I think flame graphs are easier to implement, and correspond better to the underlying data (fewer visual illusions)

Both of them take tree-shaped data, and a quantity, and you want to attribute the space of the children to the parents. For disk space it's:

    100 /home/andy/foo.txt  
     42 /home/andy/src/bar.txt

For function profiles it's

    100 f() g()
     42 f() g() h()

So you can use both visualizations with both kinds of data.

Also, ncdu is an curses UI for disk space, and I have to admit it's pretty much as effective in practice as tree maps. It doesn't necessarily give you a nice overview though.

They do not do the same thing.

A good treemap actually hides the tree structure. (From the link, the GrandPerspective one is good the Baobab one is useless due to the borders/padding). In a tree map you can see siblings, cousins, 2'nd degree cousins of similar importance (size) next to each other and you can see smaller items because size is represented as the surface of a rectangle.

On a flame graph, you can visualise the entire tree in all of it depth but since size is now just length instead of surface it is harder to compare tiny slivers. A flame graph can however be ordered by other criteria than size.

Sunbursts are circular distorted flame graphs and are of dubious utility.

Hm I prefer the Baobab one

What's an example of where you'd want to see the "siblings" ?

In my experience with disk files and function profiles, the parent-child and path to the root is what solves the problem

I love tree maps for disk space visualization.

A tree map is not used to see the tree structure. The tree is actually the information that is hidden. Especially if you use the treemap without borders/padding/bezels/names (IMO if you display those it ruins the usability of a treemap). What the tree map is good for is:

- seeing a flat representation of the entire space and therefore instantly seeing the largest files no matter how deeply nested. With a tree or a sunburst you need to drill down from largest folder to largest file because there are only so many concentric rings that can shown. With a flat file list ordered by size you lose all other information.

- seeing rough percentages by type. Maybe you have plenty of small videos taking space. Maybe you have just a few huge videos. Maybe you have one big video and plenty of small ones. All of this can be seen at a glance but is obscured by a summary by file type and is obscured by a sunburst or a tree because of depth.

- seeing the distribution of those file types. Are all of the small videos in the same place? Are they spread around and mixed with other files. Are certain types usually present together? For example if you store RAWs and Jpegs paired together you would be able to see that as a surface of two colors mixed together. If you store RAWs and Jpegs completely separated you would also be able to see that as two distinct surfaces of different colors..

- seeing similar structures. Since a tree map places surfaces near each other if they are neighbours or near neighbors in the tree structure, it is usually easy to spot duplicate trees because they look similar even when they are not identical. A duplicate finder is a separate tool and it also doesn't handle well the scenario of duplicate but changed and therefore not identical.

My problem with this is that it looks too similar to a CPU heat/component map.

And, frankly, the actual layout in treemaps is basically arbitrary. Indeed many early "disk utilization" charts that look a lot like treemaps were entirely based on physical location on the disk. As such, the logical layout was not on display, and you were only able to see the physical layout. Which was usually important, as you could see if there were obviously bad sectors or if fragmentation was out of hand.

That is, the very concept of "neighbor" that treemaps show is completely logical in nature, and doesn't really indicate any physical neighboring relationship at all. I suspect that is why I'm not a huge fan of them.

I think I agree. Treesize/windirstat’s list of folders in size order is just as useful as a treemap.

Maybe the treemap lets you hone in on the big files quicker but it only saves a few second’s really as you can expand a folder view to find the offending big files.

Maybe I am unique, but especially when you start dealing with many levels of nested directories, it is much faster to grok both the absolute and relative sizes of files and directories with a visual representation versus a textual representation like an indented list.

expanding subdirectories is suboptimal for me, too disorganized and too many directories to click.

Typically, `du -h . | sort -hr | head -n10` is more than sufficient to identify the large files for me to consider. Yes, it can be redundant, but I can't think of any time it hasn't helped me get the data I need.

I'll note that the visualizations are neat. And I certainly want to like them. But I also almost always need to know the name of the files more than anything, as it can help me decide how important a file is. If I'm impatient, I can add a `-d3` to the beginning.

> Sadly, I mostly dislike tree maps. At large, I never actually see the tree structure that they are supposedly helping me see.

I think the tree map examples in the article are missing the padding that you would add to every layer. Apparently, I didn't find any good examples with a quick search. I think this is a crucial feature of tree maps.

Why would you ever want the padding? For me the padding makes the treemap useless.

Padding in tree maps lets you extract the exact tree structure from the visualization as every layer is shown in a visible box. So it makes the visualization more useful. I found an example of such a tree map here [1].

[1] https://towardsdatascience.com/make-a-treemap-in-python-426c...

They are good for showing storage usage, because they create a direct metaphor: the sizes of the elements in the tree map corresponds to their actual proportion of space that they take up, and the tree map captures the hierarchy also: related files in the same directory (e.g. videos) are clustered into the same rectangle.

What they're missing is a link graph as given in https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-523.pdf

Uh. That's 87 pages. I'd like to have better treemaps, I don't like it 87 pages much. Mind pointing to a particular example?

What's even worse if you show it to someone unaccustomed to it, they will be just confused.

Sankey is a good alternative that is much more readable

Reply on news.ycombinator.com