Collapsing/expanding/pinning/copying tracks by SQL?

[peterthenelson-alphabet]

In the UI, there are several helpful commands to rearrange the workspace based on regex matching the track names (e.g., "Pin tracks by regex"). Is it possible to select tracks by some other method (e.g., those with slices with particular args or categories)? I can very easily generate a list of track_ids according to whatever criteria I want in SQL, but then it's not clear to me how I would use that to change the state of the workspace.

(Also, if this doesn't exist, is this something that would be doable in a plugin, and can I add it to TrackUtils?)

[LalitMaganti]

I think we'd be in favour of adding a new command to "Pin Tracks by SQL" or similar. If you want to send a PR, I think we'd be happy to review it!

[peterthenelson-alphabet]

Cool. I think I have a decent idea of how to implement it, based on playing around in the console and reading existing plugins.

1. I'm most of the way through the steps for internal contributors; waiting on approval for joining https://github.com/orgs/google/teams/perfetto-contributors
2. Could I get some advice on the UI? The easiest way to implement this is to follow the same pattern as the .*ByRegex commands (basically like getRegexFromArgOrPrompt but with a SQL query). The downside is this will look weird. It would look less weird to set the mode to Query and set the relevant placeholder text and focus, but then of course it doesn't work as a prompt. It would be easy enough to modify the renderPromptOmnibox to conditionally do something a bit different depending on the Prompt object, but this will also involve some plumbing through the Prompt interface and the omnibox.prompt() function (or alternately a new mode and even more plumbing). Knowing your preferences on how you'd like this to be wired up would save me some headaches.

[LalitMaganti]

1

Already granted access

2

I would ask for now, we implement it in the simple way with just the prompt interface. @stevegolton is out for a few days but once he's back we can figure out if there's a way we can have the plugin API define how the prompt should work (maybe by rendering mithril components etc).

[stevegolton]

I'd agree with this - the prompt interface is by far the easiest way to get started with this, and we could add a way to customize the styling of the omnibox with a prompt in the future.

[stevegolton]

Note: I originally posted this as another answer, but it makes more sense answer inline with this thread.

If you're purely looking for tracks that contain a given slice, I would avoid calculating the track_id in SQL and using that to resolve the UI track using the track tags. The UI presents a logical set of tracks that don't necessarily have a 1:1 mapping onto "trace processor" tracks. I say "not necessarily", because a lot of tracks still do but this is no longer a guarantee going forward. The UI does a lot more 'interpreting' of the raw TP tables than it used to, and I suspect we will deprecate the trackIds tags in the future.

Assuming you're actually interested in tracks that contain interesting slices, rather than being interested in the tracks themselves, we already have some infrastructure for this - you'll just need to plumb it up with a command.

You can use trace.selection.resolveSqlEvent('slice', <slice-id>) which will return the track that contains this slice. See link.

You can actually try this mechanism out using the command: Select event by table name and id > use 'slice' for the table name and the id of the slice as the id.

Here's an example of what a simple command might look light that pins tracks that contain interesting slices:

// Given a query that returns a set of slices, pin the track(s) that contain those slices
ctx.commands.registerCommand({
  id: `dev.perfetto.PinSliceTracksFromSqlQuery`,
  name: 'Pin slice tracks from SQL query',
  callback: async () => {
    const query = await ctx.omnibox.prompt('Enter SQL query...');
    if (!query) {
      return;
    }
    const result = await ctx.engine.query(query);
    const iter = result.iter({
      id: NUM,
    });
    for (; iter.valid(); iter.next()) {
      // Note this is super inefficient as resolveSqlEvent builds mappings every time it's invoked - we should modify resolveSqlEvent to take multiple slice ids
      const track = await ctx.selection.resolveSqlEvent('slice', iter.id);
      if (track) {
        ctx.workspace.getTrackByUri(track.trackUri)?.pin();
      }
    }
  },
});

Unfortunately, resolveSqlEvent does have some limitations:

1. It builds a map every time it's called, so it's inefficient if you want to resolve a list of slices - we should make it take a list of slices and return a list of tracks.
2. If multiple tracks contain the slice it arbitrarily chooses only one of the tracks - again, we should just change this.

Rationale

The reasoning for this is that over time UI tracks are getting more and more abstracted away from TP tracks, so there's not necessarily a 1:1 mapping between them; if you're searching for a given slice, there's no longer a guarantee that the slice will actually live on a track in the UI even if it has the right tag.

To put it another way, if you had a track in the UI that displayed a filtered set of events from a TP track, does it really represent that track any more? The answer is it depends what you're actually looking for. If you're looking for a slice, then it depends on whether that slice is present in the filtering criteria.

In short, instead of asking for a track when you're looking for a slice, it's better to just ask directly for the slice, then the UI can give you a much more reliable answer.

[peterthenelson-alphabet]

Ok, I'll take your advice and give this a crack later this week.