-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SDK] Grouping tracks/Fake processes #651
Comments
Hi @jamezmoran, I'm not sure whether the SDK provides this functionality, perhaps @ddiproietto will be able to provide more info here. We have a plan in the works to provide a way that users can customise the default track grouping and sorting logic purely in the UI, but this is a way off. This isn't a direct replacement for grouping, but it might help. If you don't mind building your own UI, you can create a custom plugin and, using the |
Let's discuss this within the team. It's a discussion we should have at some point. |
If we want to implement this I would go for something like that, where a single proto track is used to specify the whole hierarchy. Perhaps we can make it The alternative would be to emit truly nested tracks in the proto format. This is not trivial to do in the SDK. The SDK needs to keep track of which tracks have already been emitted. In order to support a hierarchy, it would need to traverse from child to parent, potentially grab a lock in TrackRegistry and so on. It hasn't been a high priority feature, so we haven't implemented it. I guess most of the uses of Track have to do with asynchronous events rather. |
Honestly that feels needlessly complicated. IMHO in most cases the nesting could be simply achieved with a naming convention on "using slashes as path separators" |
So I would claim this bug is partly fixed: with https://r.android.com/3283437, we now support arbitrary nesting of tracks which are nested using
|
Hi there,
We've been using the Perfetto C++ SDK to output traces to disk and then using the perfetto web viewer to visualize them. One issue we're finding is that all of our trace events are being outputted to the same collapsible process and there doesn't appear to be an obvious way to group them beyond that. For example, we have around 30 individuals tracks, and a number of tracks that we'd like to group up into a whole section as 'Hardware', or 'Audio', etc. Without any kind of grouping, it's can be pretty onerous to read the traces given the large number of tracks we have. Previously before using the SDK directly we would output everything to JSON and we could pretty much do anything, including creating fake processes for these special trace events, although for perf and space reasons we don't want to go back to doing that.
I'm wondering what the recommended course of action is here? Is there a way to group similar to a way we did with fake processes, and if not is it a planned feature? Any help would be greatly appreciated!
Thanks!
The text was updated successfully, but these errors were encountered: