Description:
To improve the performance profile of the simulation engine and ensure we are maintaining timing integrity, we need to baseline the current OpenTelemetry export logic. Currently, the telemetry path may be inducing unnecessary heap allocations and GC pressure during simulation cycles.
Goal:
Integrate BenchmarkDotNet to capture a baseline of the current OTel exporter latency and memory allocation per event.
- Create the Project: Just run
dotnet new console -n SimNextgenApp.Benchmarks in the solution folder. It does NOT need to be part of your main build pipeline yet and you can keep it as a standalone tool to probe your core engine;
- Add the dependency:
dotnet add SNA.Benchmarks package BenchmarkDotNet;
- Add the reference:
dotnet add SNA.Benchmarks reference SimNextgenApp/SimNextgenApp.csproj;
- Telemetry Baseline: Create a benchmark class
OTelExporterBenchmarks that measures the serialisation and export latency of the current implementation;
- Target the method that serialises and sends the OTel data;
- Make sure to use the
[MemoryDiagnoser] attribute on the class because that is the one that will show us the "Allocated" bytes, the smoking gun that will prove to us why a Ring Buffer is necessary.
- Metrics to Track: - Mean execution time;
Allocated (Memory per operation);Gen 0/1/2 collections (to observe GC impact).
- Baseline Target: Benchmark against a mock stream of 10k events to simulate realistic pressure.
We need empirical data to prove the performance impact of our current telemetry approach. This baseline will serve as the reference for future refactors and help us identify if the current OTel path is the root cause of observed timing jitter.
Description:
To improve the performance profile of the simulation engine and ensure we are maintaining timing integrity, we need to baseline the current OpenTelemetry export logic. Currently, the telemetry path may be inducing unnecessary heap allocations and GC pressure during simulation cycles.
Goal:
Integrate BenchmarkDotNet to capture a baseline of the current OTel exporter latency and memory allocation per event.
dotnet new console -n SimNextgenApp.Benchmarksin the solution folder. It does NOT need to be part of your main build pipeline yet and you can keep it as a standalone tool to probe your core engine;dotnet add SNA.Benchmarks package BenchmarkDotNet;dotnet add SNA.Benchmarks reference SimNextgenApp/SimNextgenApp.csproj;OTelExporterBenchmarksthat measures the serialisation and export latency of the current implementation;[MemoryDiagnoser]attribute on the class because that is the one that will show us the "Allocated" bytes, the smoking gun that will prove to us why a Ring Buffer is necessary.Allocated(Memory per operation);Gen 0/1/2collections (to observe GC impact).We need empirical data to prove the performance impact of our current telemetry approach. This baseline will serve as the reference for future refactors and help us identify if the current OTel path is the root cause of observed timing jitter.