parca-dev
Flatten the flamegraph gRPC API
Right now a flame graph is returned as nested data structure (similar to a tree). This has both some overhead in terms of computing the tree on the server-side when querying as well as when rendering the flame graph the UI has to recursively render the tree.
We can simply flatten that data to returns something like an array. This will allow us to improve rendering the icicle graph without recursion by instead computing the width and height of each span and its absolute offset in the canvas.
/cc @brancz
I don't think that on the server-side we're ever going to get around rendering the tree to some degree, however, the resulting gRPC message would be serialized more efficiently (according to a chat I had with some of the buf team).
However, you are right that on the front end this would allow parallel rendering of the iciclegraph/flamegraph since rendering can happen per level instead of recursively. I actually didn't come up with this strategy, I first learned about the approach in bvaughn/react-flame-graph.
Just to demonstrate the method, here's flamegraph that has nodes nested (this data is not how we represent it exactly but the nature is the same):
{
name: 'root',
value: 4,
children: [
{
name: 'function1',
value: 1,
},
{
name: 'function2',
value: 3,
children: [
{
name: 'function3',
value: 2
}
]
},
],
};
Whereas flattened it would be something along the lines of:
{
levels: [
{
nodes: [{
name: 'root',
value: 4,
offset: 0,
}]
}, {
nodes: [{
name: 'function1',
value: 1,
offset: 0,
}, {
name: 'function2',
value: 3,
offset: 1,
}]
}, {
nodes: [{
name: 'function3',
value: 2,
offset: 1,
}]
}
],
}
The actual width would be calculated based on the cumulative root value and the available pixels. Each level is the same height so the total height is simply a function of how many levels there are. Each level might have some additional metadata like the maximum node value, as at a certain point if there are not enough pixels available the width of a node would be less than 1 pixel at which point it doesn't make sense to render further levels as they can't be viewed on the screen anyways.
@metalmatze do you think this particular issue has been solved by the new flamegraph Arrow implementation?
