Spec must include an optional field for the original payload (e.g original JFR/pprof profile)
Jun 01 2023
Some formats (JFR) have advanced functinality that is too hard to generalize (e.g in JFR you can include custom events in your profiles)
- try to generalize it anyway, so that OTEL format is a subset of JFR
- discard such data
- generalizing it is too hard, JFR allows for pretty much any kind of message
- discarding is not good, some percentage of users depend on custom JFR events
SIG Meeting Notes from June 1 2023
Use normalized representation of profiling data
Jun 29 2023
Profiling data is different than other signals in a way that it has heavy structures with many links between them.
Use denormalized represenation of profiling data
Because profiling data has many heavy structures with many links between them, denormalized representation takes 10x more space compared to normalized version where each object references other objects by index
Github Conversation Github Conversation
When referring to other structs use array indexes for references instead of ids
Jun 29 2023
in pprof references happen using ids, e.g {function_id=123}. this leads to confusion, as these ids almost always match array indexes. e.g "function" with id=1 will usually be in functions array at index 1.
Using ids instead of indexes
- reduces confusion
- reduces serialized size
- improves performance since array lookup is faster than search (O(1) vs O(n)
Spec must include an optional Mapping struct from pprof
Jun 29 2023
pprof includes Mapping struct that describes relationships between functions and where those functions are located in the binary. This struct is rarely used in client implementations
Not include it to simplify spec
It is useful when symbol information is supplied separately, e.g very common in linux
SIG Meeting Notes from Jun 29 2023
Internal references should be uint32
Jun 29 2023
there's many internal reference fields, e.g:
- location_id
- function_id if they are > 32 bits then the payload is going to be too huge anyway
- use uint64
- uint32 is big enough
- but it's better than uint64 because it will reduce struct size in go
- this will reduct collector memory footprint