Use spans for serialization

[paulomorgado]

Addresses #6543

Changes

Refactored serialization logic to use Span<byte> for buffer manipulation, improving performance, memory efficiency, and code readability. Updated method signatures to eliminate explicit writePosition management, replaced incremental write logic with consistent += operations, and streamlined encoding methods. Enhanced test coverage to validate edge cases and updated all test cases to align with the new implementation. Applied changes consistently across all serializers, ensuring backward compatibility and laying the groundwork for future optimizations. Improved error handling, debugging, and documentation for better maintainability and robustness.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

❌ Patch coverage is 98.41897% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.73%. Comparing base (79ce1e4) to head (26deed6).
⚠️ Report is 13 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...entation/Serializer/ProtobufOtlpTraceSerializer.cs	94.44%	3 Missing ⚠️
...ementation/Serializer/ProtobufOtlpLogSerializer.cs	95.65%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6544      +/-   ##
==========================================
- Coverage   86.75%   86.73%   -0.02%     
==========================================
  Files         258      258              
  Lines       11956    11952       -4     
==========================================
- Hits        10372    10367       -5     
- Misses       1584     1585       +1     

Flag	Coverage Δ
unittests-Project-Experimental	86.67% <98.41%> (-0.07%)	⬇️
unittests-Project-Stable	86.70% <98.41%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ntation/Serializer/ProtobufOtlpMetricSerializer.cs	98.90% <100.00%> (-0.02%)	⬇️
...ation/Serializer/ProtobufOtlpResourceSerializer.cs	91.66% <100.00%> (ø)
...Implementation/Serializer/ProtobufOtlpTagWriter.cs	95.94% <100.00%> (ø)
...ol/Implementation/Serializer/ProtobufSerializer.cs	91.50% <100.00%> (-0.08%)	⬇️
...ementation/Serializer/ProtobufOtlpLogSerializer.cs	98.48% <95.65%> (ø)
...entation/Serializer/ProtobufOtlpTraceSerializer.cs	95.01% <94.44%> (ø)

... and 1 file with indirect coverage changes

[paulomorgado]

Hi @martincostello, @Kielek, can you help me here with the test failures?

[martincostello]

Put the blank line back, and the style analyser won't fail the build.

[Kielek]

In general, it is good practice to run local build in Release mode. Debug allows to compile with Warnings, Release is extremely strict.

[paulomorgado]

My bad! Sorry!

I have fixed the style errors, but I still have a test failing:

Failed OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests.OtlpAttributeTests.IntegralTypesSupported(value: [1, 2, 3]) [< 1 ms]
Error Message:
 Google.Protobuf.InvalidProtocolBufferException : Protocol message contained an invalid tag (zero).

I can't figure out how this is related to my changes.

Runing the tests in debug mode I get this:

 OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests.OtlpAttributeTests.IntegralTypesSupported(value: [1, 2, 3])
   Source: OtlpAttributeTests.cs line 56
   Duration: 7 ms

  Message: 
Microsoft.VisualStudio.TestPlatform.TestHost.DebugAssertException : Method Debug.Fail failed with 'bytesWritten did not match numberOfUtf8CharsInString
', and was translated to Microsoft.VisualStudio.TestPlatform.TestHost.DebugAssertException to avoid terminating the process hosting the test.

  Stack Trace: 
TestHostTraceListener.GetException(String message)
TestHostTraceListener.Fail(String message, String detailMessage)
TraceInternal.Fail(String message, String detailMessage)
Debug.Fail(String message, String detailMessage)
ProtobufOtlpTagWriter.TryWriteByteArrayTag(OtlpTagWriterState& state, String key, ReadOnlySpan`1 value) line 94
TagWriter`2.TryWriteTag(TTagState& state, String key, Object value, Nullable`1 tagValueMaxLength) line 70
TagWriter`2.TryWriteTag(TTagState& state, KeyValuePair`2 tag, Nullable`1 tagValueMaxLength) line 28
OtlpAttributeTests.TryTransformTag(KeyValuePair`2 tag, KeyValue& attribute) line 293
OtlpAttributeTests.IntegralTypesSupported(Object value) line 59

This happens because ProtobufOtlpTagWriter.TryWriteByteArrayTag is calling ProtobufSerializer.WriteStringWithTag with ProtobufOtlpCommonFieldNumberConstants.KeyValue_Key (1) for numberOfUtf8CharsInString with key as "key".

What am I missing here?

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[martincostello]

It would be good to get some before and after benchmarks on the changes here.

Looking at the diff I have a slight concern that API has changed in a way that makes it harder to use/easier to make a mistake (e.g. use = instead of +=).

Numbers on the performance difference the change makes would help guide whether the gain is worth it if there's no way to refactor to make it easier to not misuse the methods (e.g. maybe remove the return value and pass the write position as a ref?).

[paulomorgado]

It would be good to get some before and after benchmarks on the changes here.

Looking at the diff I have a slight concern that API has changed in a way that makes it harder to use/easier to make a mistake (e.g. use = instead of +=).

Numbers on the performance difference the change makes would help guide whether the gain is worth it if there's no way to refactor to make it easier to not misuse the methods (e.g. maybe remove the return value and pass the write position as a ref?).

That's why I changed (I hope everywhere) the variable/parameter name from writePosition to bytesWritten.

This should probably be better with a ref Span<byte> and returning bytes written to the caller to use if needed.

There is still an issue with state structs with a byte[] parameter that cannot be a field. It needs to be a method parameter or a Memory<byte> and I don't want to do the latter.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.