[SDK] Grouping tracks/Fake processes

[jamezmoran]

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!

[stevegolton]

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 pinTrackByPredicate API, create a command that pins a certain number of interesting tracks, similar to this.

[primiano]

Let's discuss this within the team. Regardless of a UI plugin (which could solve the problem by doing custom grouping), it feels like there should be a way with the SDK to group tracks into "things that are not just processes"

It's a discussion we should have at some point. I feel at very least we could have something along the lines of: if you create a global track, and name something like "peripherals/bluetooth/tx_queue" that shows up as a nested track group in the UI.

@ddiproietto

[ddiproietto]

I feel at very least we could have something along the lines of: if you create a global track, and name something like "peripherals/bluetooth/tx_queue" that shows up as a nested track group in the UI.

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.

[primiano]

The alternative would be to emit truly nested tracks in the proto format.

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"

[LalitMaganti]

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 parent_uuid in the SDK. However, this is still a bit of a hack because you need to pretend these groups are fake processes. We should do the following 1) For people using the SDK, we should add support for adding tracks which are neither processes nor threads but just have a name 2) For people emitting synthetic traces, we want to come up with a new format which will allow emitting data easier and, when it does, it should also support non-thread/process groups.