You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current internal format for exportable telemetry like spans and metrics (and maybe events) does not match the format expected by the protobuf serialization library we are using. In order to serialize protobuf, this means we have to create new objects with new property names, recursively, for every exported object.
We cannot change the internal representation, because it would be a breaking change for exporter interfaces. Specifically, the SpanProcessor, MetricReader, and Exporter interfaces expect our existing internal formats.
The problem
The overhead for this is quite substantial in a few different ways:
The CPU cost of iterating through every property of every object recursively
The memory cost of creating every object twice (one internal representation and one protobuf representation)
The bundle size cost of including the transformation library, which must contain the full name of every property in both representations
The GC cost of reclaiming the memory for every object in multiple representations
Potential Solutions
Use getters to alias the protobuf names to our internal names. This avoids excess object allocations and cpu iterations at the cost of bundle sizes.
Write a custom protobuf serializer. This would avoid all of the above costs at the expense of developer time and resources. It is likely the best technical choice, but we may not have the resources to take on such a task and guarantee it is updated as OTLP continues to add features.
The text was updated successfully, but these errors were encountered:
Background
Our current internal format for exportable telemetry like spans and metrics (and maybe events) does not match the format expected by the
protobuf
serialization library we are using. In order to serialize protobuf, this means we have to create new objects with new property names, recursively, for every exported object.We cannot change the internal representation, because it would be a breaking change for exporter interfaces. Specifically, the
SpanProcessor
,MetricReader
, andExporter
interfaces expect our existing internal formats.The problem
The overhead for this is quite substantial in a few different ways:
Potential Solutions
The text was updated successfully, but these errors were encountered: