Advanced Guide to Programmatic Trace Generation

This page serves as an advanced reference for programmatically creating Perfetto trace files. It builds upon the foundational concepts and examples presented in "Converting arbitrary timestamped data to Perfetto".

We assume you are familiar with:

• The basic structure of Perfetto traces (a Trace message containing a stream of TracePacket messages).
• Using the TrackEvent payload within TracePacket to create custom tracks with various types of slices (simple, nested, asynchronous), counters, and flows.
• The Python script template (trace_converter_template.py) for generating traces, and that the Python examples provided here are intended to be used within its populate_packets(builder) function.

This guide will currently focus on advanced TrackEvent features, such as:

• Associating your timeline data with operating system (OS) processes and threads for richer integration.
• Explicit track sorting and data interning for optimizing trace size and detail.

While TrackEvent is a primary method for representing timeline data, TracePacket is a versatile container. In the future, this guide may expand to cover other TracePacket payloads useful for synthetic trace generation.

The examples will continue to use Python, but the principles apply to any language with Protocol Buffer support. For complete definitions of all available fields, always refer to the official Perfetto protobuf sources, particularly TracePacket and its various sub-messages, including TrackEvent.

Associating Tracks with Operating System Concepts

While the "Converting arbitrary timestamped data to Perfetto" guide demonstrated creating generic custom tracks, you can provide more specific context to Perfetto by associating your tracks with operating system (OS) processes and threads. This allows Perfetto's UI and analysis tools to offer richer integration and better correlation with other system-wide data.

Associating Tracks with Processes

You can create a top-level track that represents an OS process. Any other custom tracks (which might contain slices or counters) can then be parented to this process track. This helps in:

• UI Grouping: Your custom tracks will appear under the specified process name and PID in the Perfetto UI, alongside any other data collected for that process (e.g., CPU scheduling, memory counters).
• Correlation: Events on your custom tracks can be more easily correlated with system-level activity related to that process.
• Clear Identification: Explicitly naming the process and providing its PID makes it unambiguous which process your custom data pertains to.

To define a process track, you populate the process field within its TrackDescriptor. At a minimum, you should provide a pid and ideally a process_name.

Python Example

Let's say you want to emit a custom counter (e.g. "Active DB Connections") and have it appear under a specific process named "MyDatabaseService" with PID 1234.

Copy the following Python code into the populate_packets(builder) function in your trace_converter_template.py script.

TODO: this looks like so.

Once you have defined a process track, you can parent various other kinds of tracks to it. This includes tracks for specific threads within that process (see next section), as well as custom tracks for process-wide counters (as shown above) or groups of asynchronous operations related to this process (using the techniques for asynchronous slices described in the "Converting arbitrary timestamped data to Perfetto" guide).

Associating Tracks with Threads

You can create tracks that are explicitly associated with specific threads within an OS process. This is the most common way to represent thread-specific activity, such as function call stacks or thread-local counters.

Benefits:

• Correct UI Placement: When a thread track's pid and tid are specified in its TrackDescriptor, the Perfetto UI typically groups it under the corresponding process (identified by that pid). This helps organize the trace.
• Correlation with System Data: Perfetto can automatically correlate events on your thread track with system-level data for that thread, such as CPU scheduling slices.
• Clear Naming: You can provide a human-readable name for your thread.

To define a thread track:

1. Create a TrackDescriptor for the thread.
2. Populate its thread field, providing the pid of the process this thread belongs to and the unique tid of the thread. You should also set thread_name.
3. Optionally and encouraged, you can also define a separate TrackDescriptor for the parent process itself (using its process field and pid), though it's not strictly required for the thread track to be recognized as a thread of that PID. The UI often infers process groupings from PIDs present in thread tracks.

Python Example: Thread-Specific Slices

This example defines a thread "MainWorkLoop" (TID 5678) belonging to process "MyApplication" (PID 1234). It then emits a couple of slices directly onto this thread's track. We also define a track for the process itself for clarity, though the thread track's association is primarily through its pid and tid fields.

Copy the following Python code into the populate_packets(builder) function in your trace_converter_template.py script.

TODO: this looks like so.

Advanced Track Customization

Beyond associating tracks with OS concepts, Perfetto offers ways to fine-tune how your tracks are presented and how data is encoded.

Controlling Track Sorting Order

By default, the Perfetto UI applies its own heuristics to sort tracks (e.g., alphabetically by name, or by track UUID). However, for complex custom traces, you might want to explicitly define the order in which sibling tracks appear under a parent. This is achieved using the child_ordering field on the parent TrackDescriptor and, for EXPLICIT ordering, the sibling_order_rank on the child TrackDescriptors.

This child_ordering setting on a parent track only affects its direct children.

Available child_ordering modes (defined in TrackDescriptor.ChildTracksOrdering):

• ORDERING_UNSPECIFIED: The default. The UI will use its own heuristics.
• LEXICOGRAPHIC: Child tracks are sorted alphabetically by their name.
• CHRONOLOGICAL: Child tracks are sorted based on the timestamp of the earliest TrackEvent that occurs on each of them. Tracks with earlier events appear first.
• EXPLICIT: Child tracks are sorted based on the sibling_order_rank field set in their respective TrackDescriptors. Lower ranks appear first. If ranks are equal, or if sibling_order_rank is not set, the tie-breaking order is undefined.

Note: The UI treats these as strong hints. While it generally respects these orderings, there are contexts in which the UI reserves the right not to show them in this order; generally this would be if the user explicitly requested this or if the UI has some special handling for these tracks.

Python Example: Demonstrating All Sorting Types

This example defines three parent tracks, each demonstrating a different child_ordering mode.

Copy the following Python code into the populate_packets(builder) function in your trace_converter_template.py script.

TODO: this looks like so.

Interning Data for Trace Size Optimization

Interning is a technique used to reduce the size of trace files by emitting frequently repeated strings (like event names or categories) only once in the trace. Subsequent references to these strings use a compact integer identifier (an "interning ID" or iid). This is particularly useful when you have many events that share the same name or other string-based attributes.

How it works:

1. Define Interned Data: In a TracePacket, you include an interned_data message. Inside this, you map your strings to iids. For example, you can define event_names where each entry has an iid (a non-zero integer you choose) and a name string. This packet establishes the mapping.

2. Reference by IID: In subsequent TrackEvents (within the same trusted_packet_sequence_id and before the interned state is cleared), instead of setting the name field directly, you set the corresponding name_iid field to the integer iid you defined.

3. Sequence Flags: The TracePacket.sequence_flags field is crucial:

   • SEQ_INCREMENTAL_STATE_CLEARED (value 1): Set this on a packet if the interning dictionary (and other incremental state) for this sequence should be considered reset before processing this packet's interned_data. This is often used on the first packet of a sequence that defines interned entries.
   • SEQ_NEEDS_INCREMENTAL_STATE (value 2): Set this on any packet that either defines new interned data entries OR uses iids that were defined in previous packets (within the current valid state of the sequence).

   A typical packet that initializes the interning dictionary for a sequence will set both flags: TracePacket.SEQ_INCREMENTAL_STATE_CLEARED | TracePacket.SEQ_NEEDS_INCREMENTAL_STATE. Packets that use these established interned entries (or add more entries to the existing valid dictionary) will set TracePacket.SEQ_NEEDS_INCREMENTAL_STATE.

Python Example: Interning Event Names

This example shows how to define an interned string for an event name and then use it multiple times.

Copy the following Python code into the populate_packets(builder) function in your trace_converter_template.py script.

TODO: this looks like so.