You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand graphviz is doing most of the heavy lifting when it comes to visualization with this approach. Unfortunately, I don't think treemaps are the right approach for this use case. Usually, a treemap would be used for a bottom-up approach where we start with a given branch and want to know it's cumulative weight, including that of all the leaves 'owned' by the branch. E.g., all of the files nested under a given directory in a file system.
However, in the case of docker images, our interest is reversed. We'd prefer a top-down approach where we're interested in a particular peak in a mountain range and we want to determine the weight of all the supporting strata, including those which might also be undergirding other peaks. In the top-down analysis, a supporting stratum isn't necessarily 'owned' solely by a single peak.
In short, treemaps = sum(for all descendants of branch) analysis
...but for docker images we want: sum(for all ancestors of leaf) analysis
To that end, I think a better visualization would look more like a flamegraph or sunburst chart where we'd have more abstract/general/foundational building blocks across the bottom and more concrete/specific/dependent building blocks stacked up on top of their respective underlying dependencies. The area of any given block would be proportional to it's size in bytes.
Thanks for dockviz!
I understand graphviz is doing most of the heavy lifting when it comes to visualization with this approach. Unfortunately, I don't think treemaps are the right approach for this use case. Usually, a treemap would be used for a bottom-up approach where we start with a given branch and want to know it's cumulative weight, including that of all the leaves 'owned' by the branch. E.g., all of the files nested under a given directory in a file system.
However, in the case of docker images, our interest is reversed. We'd prefer a top-down approach where we're interested in a particular peak in a mountain range and we want to determine the weight of all the supporting strata, including those which might also be undergirding other peaks. In the top-down analysis, a supporting stratum isn't necessarily 'owned' solely by a single peak.
In short,
treemaps = sum(for all descendants of branch)
analysis...but for docker images we want:
sum(for all ancestors of leaf)
analysisTo that end, I think a better visualization would look more like a flamegraph or sunburst chart where we'd have more abstract/general/foundational building blocks across the bottom and more concrete/specific/dependent building blocks stacked up on top of their respective underlying dependencies. The area of any given block would be proportional to it's size in bytes.
Flame graphs: http://www.brendangregg.com/flamegraphs.html
Sunburst chart: https://architect-api.readthedocs.io/en/latest/text/document-vis-hierarchy.html#sunburst-chart
The main difference when compared to a regular flame graph is that the more dependent layers aren't necessarily constrained to be smaller than their dependencies. Some graphs might be top-heavy e.g., https://i.pinimg.com/736x/d3/79/61/d3796140d9104796457d8d26986c9f56.jpg
The text was updated successfully, but these errors were encountered: