Bugzilla

I'm taking this bug for the Marker 2.0 spec.

The work here is to add a `tracingIndex` field to the marker table in the Gecko profile format. The field will be an array of either `null` or `integer`. This field will reference a unique tracing event that can be re-constructed via a start and end marker. Currently, profiler.firefox.com matches up start and end markers where it can find them, but this is can be difficult on deciding on what's correct, and requires markers to be properly nested.

This work will add a `tracingIndex` which has the following semantic meaning, note that I'm using pseudo-code to represent the final markers. In the Gecko format they will be in a tuple with a schema, and then converted on the front-end.


Non-interval marker, a single point in time.
```
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: null
}

These two would collapse into a single interval marker:
```
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: 54
} 
{
  startTime: null,
  endTime: 485454494567,
  tracingIndex: 54
}
```

```
If only one marker with the index is found, and a start time, then it is assumed to run until the end of the thread time.
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: 54
}
```

If only one marker with the index is found, then it is assumed to run from the start of the thread time.
```
{
  startTime: null,
  endTime: 485454492123,
  tracingIndex: 54
}
```

This would handle all cases of creating markers, and fix a few bugs we have on file for markers not being complete.

I'm taking this bug for the Marker 2.0 spec.

The work here is to add a `tracingIndex` field to the marker table in the Gecko profile format. The field will be an array of either `null` or `integer`. This field will reference a unique tracing event that can be re-constructed via a start and end marker. Currently, profiler.firefox.com matches up start and end markers where it can find them, but this is can be difficult on deciding on what's correct, and requires markers to be properly nested.

This work will add a `tracingIndex` which has the following semantic meaning, note that I'm using pseudo-code to represent the final markers. In the Gecko format they will be in a tuple with a schema, and then converted on the front-end.


Non-interval marker, a single point in time.
```
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: null
}
```

These two would collapse into a single interval marker:
```
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: 54
} 
{
  startTime: null,
  endTime: 485454494567,
  tracingIndex: 54
}
```

```
If only one marker with the index is found, and a start time, then it is assumed to run until the end of the thread time.
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: 54
}
```

If only one marker with the index is found, then it is assumed to run from the start of the thread time.
```
{
  startTime: null,
  endTime: 485454492123,
  tracingIndex: 54
}
```

This would handle all cases of creating markers, and fix a few bugs we have on file for markers not being complete.

I'm taking this bug for the Marker 2.0 spec.

The work here is to add a `tracingIndex` field to the marker table in the Gecko profile format. The field will be an array of either `null` or `integer`. This field will reference a unique tracing event that can be re-constructed via a start and end marker. Currently, profiler.firefox.com matches up start and end markers where it can find them, but this is can be difficult on deciding on what's correct, and requires markers to be properly nested.

This work will add a `tracingIndex` which has the following semantic meaning, note that I'm using pseudo-code to represent the final markers. In the Gecko format they will be in a tuple with a schema, and then converted on the front-end.


Non-interval marker, a single point in time.
```
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: null
}
```

These two would collapse into a single interval marker:
```
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: 54
} 
{
  startTime: null,
  endTime: 485454494567,
  tracingIndex: 54
}
```

If only one marker with the index is found, and a start time, then it is assumed to run until the end of the thread time.
```
{
  startTime: 485454492123,
  endTime: null,
  tracingIndex: 54
}
```

If only one marker with the index is found, then it is assumed to run from the start of the thread time.
```
{
  startTime: null,
  endTime: 485454492123,
  tracingIndex: 54
}
```

This would handle all cases of creating markers, and fix a few bugs we have on file for markers not being complete.