We're playing around with using Speedscope to visualize a Javascript bundle/module dependency graph, using the speedscope.json format. So far the Sandwich view has been the most helpful, but we're running into a problem with shared modules. With timing data, it makes sense to aggregate multiple call stacks by summing their weights, but with size data it just multiplies the size of each dependency by the number of parents.
This isn't an issue with the Left-heavy view, since it doesn't try to aggregate different caller stacks. But that view is not as nice to navigate.
We've tried a couple of ways of formatting our data, none of which have been perfect:
We started with an algorithm that only included each module the first time it was encountered. This gave accurate sizes for the module itself, but now the dependency graph is incorrect for all the subsequent dependees.
We also tried splitting each entrypoint into a unique Profile - this reduced the problem, but you're no longer able to see where modules are used across multiple entrypoints, and shared modules within an entrypoint are still problematic
And we've ended up with the current solution of smushing everything into one Profile, and just mentally reminding ourselves to divide by the number of parents to get the actual size (or to check the Left-heavy view)
I think in a sense we're trying to assign weights to the Frame rather than to each sample, if that makes sense. Or maybe aggregate samples by taking the average rather than the sum. I'm not sure if there's some other way to structure our samples that would solve this.
We're playing around with using Speedscope to visualize a Javascript bundle/module dependency graph, using the speedscope.json format. So far the Sandwich view has been the most helpful, but we're running into a problem with shared modules. With timing data, it makes sense to aggregate multiple call stacks by summing their weights, but with size data it just multiplies the size of each dependency by the number of parents.
This isn't an issue with the Left-heavy view, since it doesn't try to aggregate different caller stacks. But that view is not as nice to navigate.
We've tried a couple of ways of formatting our data, none of which have been perfect:
I think in a sense we're trying to assign weights to the
Framerather than to each sample, if that makes sense. Or maybe aggregate samples by taking the average rather than the sum. I'm not sure if there's some other way to structure our samples that would solve this.