Switch to allocation-free enumeration of `Activity` objects#8041

andrewlock · 2026-01-08T16:07:36Z

Summary of changes

Update code that enumerates properties of IActivity duck types to use allocation-free enumeration

Reason for change

Our duck types all use the public APIs of Activity to grab tags, events, and links. These types are generally implemented internally as custom linked list objects, but are exposed as IEnumerable<> types. The internal types implement a struct-based enumerator, but as the types aren't exposed directly, the compiler can't use those and ends up allocating. That's... annoying.

To work around that, this adds a "hack" that OTel were actually using themselves (and which has been discussed elsewhere), of building a dynamic method that finds the GetEnumerator type and uses that. We can't use it everywhere because we don't have the types available (e.g. links and events), but we can use it for tags. There's essentially a trade-off of startup time vs runtime allocation, which is worth it in this case IMO.

Additionally, the Activity implementation uses an empty array as the return value when there are no tags/links/events, so we can avoid the enumerator allocation in those cases by specifically looking for an empty array and bailing if so.

Implementation details

I chose to add the EnumerationHelper as an explicitly Activity-related thing for now, but we can consider exposing this more widely if we get confidence.

I also avoided the concurrent dictionary approach that is the "default" for this, and instead added an additional helper to read a static field that we populate once. We have to wait until we have a "real" activity to do the population, so that we get the right type, which is a bit annoying, but it works...

Test coverage

Added a couple of unit tests for the result and confirmed it works as expected. Benchmarks vs #8040 shw a nice allocation improvement:

Method	Runtime	Mean	StdDev	Gen0	Gen1	Allocated	Compared to #8040
StartStopWithChild_Hierarchical	.NET 6.0	3,248.6 ns	28.71 ns	0.0114	0.0038	3.6 KB	-0.19 KB
StartStopWithChild_Hierarchical	.NET 8.0	2,651.1 ns	80.80 ns	0.0114	-	3.6 KB	-0.19 KB
StartStopWithChild_Hierarchical	.NET Core 3.1	4,482.2 ns	263.51 ns	0.0153	-	3.83 KB	-0.19 KB
StartStopWithChild_Hierarchical	.NET Framework 4.7.2	4,915.8 ns	63.81 ns	0.7019	-	4.33 KB	-0.18 KB
StartStopWithChild	.NET 6.0	3,176.8 ns	37.73 ns	0.0114	-	3.59 KB	-0.19 KB
StartStopWithChild	.NET 8.0	2,598.0 ns	40.05 ns	0.0114	-	3.59 KB	-0.19 KB
StartStopWithChild	.NET Core 3.1	4,260.7 ns	59.98 ns	0.0076	-	3.78 KB	-0.19 KB
StartStopWithChild	.NET Framework 4.7.2	5,097.7 ns	46.98 ns	0.6790	-	4.2 KB	-0.19 KB

Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-915

Part of a stack working to improve OTel performance

bouwkast · 2026-01-08T20:31:44Z

tracer/src/Datadog.Trace/Activity/Helpers/ActivityEnumerationHelper.cs

+{
+    private static AllocationFreeEnumerator<IEnumerable<KeyValuePair<string, object?>>, KeyValuePair<string, object?>, OtelTagsEnumerationState>.AllocationFreeForEachDelegate? _tagObjectsEnumerator;
+    private static AllocationFreeEnumerator<IEnumerable<KeyValuePair<string, string?>>, KeyValuePair<string, string?>, OtelTagsEnumerationState>.AllocationFreeForEachDelegate? _tagsEnumerator;
+#if DEBUG


What exactly are the #if DEBUG for?

The "risk" with these helpers are that you must always call this method with the same runtime-type of object. This is generally guaranteed with the current usage, but there's a risk, if you use it incorrectly, that we pass in a different type. The DEBUG were intended as some simple guard rails to try to catch invalid behaviour locally, without adding overhead at runtime.

There are a couple of (safer) alternatives

Add the GetType() call in every case, and bail if it's wrong. Small bit of extra overhead, for runtime safety

Reinstate the ConcurrentDictionary lookup based on GetType(), and build new enumerators as necessary. This is slower (due to the dictionary lookup), but it does guarantee we'll always be able to do the lookup even if they do more stuff like "return type A in some cases, and type B in other cases"...

I'm ok with those other two options, I've just been pushing hard for speed, so was erring on that side, but I've maybe gone too far now 😅

After some soul searching (thanks @tonyredondo) decided to refactor this to be always safe, instead of only in DEBUG mode 😄 Now, if the provided type doesn't match the provided type it's an error, but we fallback to doing an allocating enumeration instead

tracer/src/Datadog.Trace/Activity/Helpers/AllocationFreeEnumerator.cs

bouwkast · 2026-01-08T20:36:31Z

tracer/src/Datadog.Trace/Activity/Helpers/OtelTagsEnumerationState.cs

+
+namespace Datadog.Trace.Activity.Helpers;
+
+internal readonly struct OtelTagsEnumerationState(Span span)


This is to avoid the closure allocation right? It might be good to leave a comment stating that so it doesn't get refactored away accidentally

Yeah, essentially, but mostly it's because AllocationFreeEnumerator requires the state is a struct 😄 I'll add a comment to it 👍

## Summary of changes Update `Activity`-based benchmarks to reduce variability and make comparisons easier ## Reason for change The various `Activity`-related benchmarks call the global `Tracer` instance, so we should make sure to configure it with our default benchmarking settings (basically disabling background jobs like telemetry/discovery/remote config) to reduce variation. Also added a "baseline" job for comparison and a version that uses hiearachical IDs instead of W3C IDs. Was a prerequisite for a bunch of other work. ## Implementation details - Configure `Benchmarks.OpenTelemetry.InstrumentedApi` project and `Benchmarks.Trace/ActivityBenchmark` to setup the global tracer with Telemetry etc disabled - Add two extra benchmarks to `Benchmarks.Trace/ActivityBenchmark` - `StartStopWithChild_Baseline`, which is the same as `StartStopWithChild` but without the DD integration - `StartStopWithChild_Hierarchical`, which is the same as `StartStopWithChild` but uses hierarchical ID format - Don't run either of these in CI for now (to avoid extra load), just for local comparisons - Simplify the benchmark to just do explicit duck typing (which is closer to what we do normally anyway, and removes a bunch of code) ## Test coverage Running these benchmarks locally shows the improvements we need to make, and highlights that we clearly have a bug with hierarchical IDs 😬 | Method | Runtime | Mean | Error | StdDev | Gen0 | Gen1 | Allocated | | ------------------------------- | -------------------- | ----------: | ----------: | ----------: | -----: | -----: | --------: | | StartStopWithChild_Baseline | .NET 6.0 | 672.9 ns | 23.23 ns | 66.66 ns | 0.0038 | - | 1.09 KB | | StartStopWithChild_Hierarchical | .NET 6.0 | 35,478.1 ns | 1,035.96 ns | 3,021.94 ns | - | - | 10.47 KB | | StartStopWithChild | .NET 6.0 | 3,681.7 ns | 50.23 ns | 44.53 ns | 0.0153 | - | 4.87 KB | | StartStopWithChild_Baseline | .NET 8.0 | 570.8 ns | 16.96 ns | 49.22 ns | 0.0029 | - | 1.09 KB | | StartStopWithChild_Hierarchical | .NET 8.0 | 32,478.5 ns | 1,215.04 ns | 3,466.57 ns | - | - | 10.48 KB | | StartStopWithChild | .NET 8.0 | 3,021.4 ns | 59.24 ns | 163.16 ns | 0.0153 | - | 4.77 KB | | StartStopWithChild_Baseline | .NET Core 3.1 | 752.6 ns | 15.06 ns | 30.09 ns | 0.0038 | - | 1.19 KB | | StartStopWithChild_Hierarchical | .NET Core 3.1 | 34,170.1 ns | 572.80 ns | 478.31 ns | - | - | 10.75 KB | | StartStopWithChild | .NET Core 3.1 | 4,905.0 ns | 31.63 ns | 29.58 ns | 0.0153 | - | 5.05 KB | | StartStopWithChild_Baseline | .NET Framework 4.7.2 | 770.7 ns | 6.03 ns | 5.64 ns | 0.2012 | - | 1.24 KB | | StartStopWithChild_Hierarchical | .NET Framework 4.7.2 | 37,386.2 ns | 542.73 ns | 453.21 ns | 1.8921 | 0.1221 | 11.77 KB | | StartStopWithChild | .NET Framework 4.7.2 | 5,884.5 ns | 64.54 ns | 60.37 ns | 0.8621 | - | 5.3 KB | ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-915 Part of a stack working to improve OTel performance - #8036 👈 - #8037 - #8038 - #8039 - #8040 - #8041 - #8042

## Summary of changes Reduce allocation of `ActivityHandlerCommon` by removing `string` concatenation ## Reason for change The `ActivityHandlerCommon.ActivityStarted` and `ActivityStopped` methods need to store and retrieve `Activity` instances from a `ConcurrentDictionary<>`. Today they're doing that be concatenating the `Activity`'s `TraceId` and `SpanID`, or by using it's `ID`. All that concatenation causes a bunch of allocation, so instead introduce a simple `struct` to use as the key instead ## Implementation details Introduce `ActivityKey`, which is essentially `internal readonly record struct ActivityKey(string TraceId, string SpanId`, and use that for all of the dictionary lookups. Which avoids all the string concatenation allocations. ## Test coverage Added some unit tests for `ActivityKey`, by mostly covered by existing integration tests for correctness. Benchmarks show a significant improvement over [the previous results](#8036), particularly for Hierachical IDs which clearly were buggy | Method | Runtime | Mean | StdDev | Gen0 | Allocated | Compared to #8036 | | ------------------------------- | -------------------- | -------: | --------: | -----: | --------: | ----------------: | | StartStopWithChild_Hierarchical | .NET 6.0 | 4.217 us | 0.3227 us | 0.0153 | 4.09 KB | -6.38 KB | | StartStopWithChild_Hierarchical | .NET 8.0 | 3.413 us | 0.2505 us | 0.0076 | 4.09 KB | -6.39 KB | | StartStopWithChild_Hierarchical | .NET Core 3.1 | 5.676 us | 0.4636 us | 0.0153 | 4.32 KB | -6.43 KB | | StartStopWithChild_Hierarchical | .NET Framework 4.7.2 | 6.813 us | 0.4969 us | 0.7324 | 4.53 KB | -7.24 KB | | | | | | | | | | StartStopWithChild | .NET 6.0 | 4.105 us | 0.2677 us | 0.0153 | 4.3 KB | -0.57 KB | | StartStopWithChild | .NET 8.0 | 3.475 us | 0.1570 us | 0.0114 | 4.2 KB | -0.57 KB | | StartStopWithChild | .NET Core 3.1 | 5.647 us | 0.3129 us | 0.0153 | 4.48 KB | -0.57 KB | | StartStopWithChild | .NET Framework 4.7.2 | 6.842 us | 0.2992 us | 0.7629 | 4.69 KB | -0.61 KB | ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-915 Part of a stack working to improve OTel performance - #8036 - #8037 👈 - #8038 - #8039 - #8040 - #8041 - #8042

## Summary of changes Fix incorrect nullable annotations on `Activity` duck types ## Reason for change While working on other performance things, noticed that the nullable annotations often declared non-nullability when they actually could be null. A particularly confusing part are the `TraceId` and `SpanId` values in `IW3CActivity`. These were marked non-nullable because when you call `Activity.Start()` then these will always be non-null, but _only_ if you're using W3C IDs. If you're using hierarchical IDs ([the default in <.NET 5](https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/default-activityidformat-changed)) then these values _will_ be null. As a side note, I suspect this explains the "we saw errors about these being null in error tracking but don't understand why" scenarios 😄 Also, I think we should rename `IW3CActivity` to `IActivity3` instead. W3C _implies_ that it's a W3C activity, but that's not necessarily the case, and is essentially the source of the above confusion I think. `IActivity3` would then be consistently named with `IActivity5` and `IActivity6` we also currently have. ## Implementation details Add nullable annotations to values that _can_ be null, and fix the fallout (mostly in `ActivityKey`) ## Test coverage Covered by existing tests sufficiently I think ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-915 Part of a stack working to improve OTel performance - #8036 - #8037 👈 - #8038 - #8039 - #8040 - #8041 - #8042

tonyredondo

👏🏻 👏🏻 👏🏻

tracer/src/Datadog.Trace/Activity/Helpers/AllocationFreeEnumerator.cs

dd-trace-dotnet-ci-bot · 2026-01-09T18:51:59Z

Execution-Time Benchmarks Report ⏱️

Execution-time results for samples comparing This PR (8041) and master.

✅ No regressions detected - check the details below

Full Metrics Comparison

FakeDbCommand

Metric	Master (Mean ± 95% CI)	Current (Mean ± 95% CI)	Change	Status
.NET Framework 4.8 - Baseline
duration	68.49 ± (68.51 - 68.80) ms	68.19 ± (68.19 - 68.41) ms	-0.4%	✅
.NET Framework 4.8 - Bailout
duration	72.45 ± (72.39 - 72.61) ms	72.08 ± (72.06 - 72.25) ms	-0.5%	✅
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration	1010.14 ± (1018.97 - 1030.33) ms	1002.01 ± (1004.17 - 1010.54) ms	-0.8%	✅
.NET Core 3.1 - Baseline
process.internal_duration_ms	22.00 ± (21.95 - 22.05) ms	22.04 ± (22.01 - 22.08) ms	+0.2%	✅⬆️
process.time_to_main_ms	79.11 ± (78.92 - 79.30) ms	78.54 ± (78.42 - 78.67) ms	-0.7%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.93 ± (10.93 - 10.94) MB	10.92 ± (10.92 - 10.93) MB	-0.1%	✅
runtime.dotnet.threads.count	12 ± (12 - 12)	12 ± (12 - 12)	+0.0%	✅
.NET Core 3.1 - Bailout
process.internal_duration_ms	21.81 ± (21.78 - 21.83) ms	21.95 ± (21.93 - 21.98) ms	+0.7%	✅⬆️
process.time_to_main_ms	79.91 ± (79.81 - 80.02) ms	79.78 ± (79.70 - 79.86) ms	-0.2%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.94 ± (10.94 - 10.95) MB	10.93 ± (10.93 - 10.94) MB	-0.1%	✅
runtime.dotnet.threads.count	13 ± (13 - 13)	13 ± (13 - 13)	+0.0%	✅
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms	244.61 ± (240.85 - 248.37) ms	235.55 ± (231.40 - 239.71) ms	-3.7%	✅
process.time_to_main_ms	471.48 ± (470.94 - 472.01) ms	471.73 ± (471.18 - 472.28) ms	+0.1%	✅⬆️
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	48.30 ± (48.27 - 48.32) MB	48.30 ± (48.28 - 48.32) MB	+0.0%	✅⬆️
runtime.dotnet.threads.count	28 ± (28 - 28)	28 ± (28 - 28)	-0.5%	✅
.NET 6 - Baseline
process.internal_duration_ms	20.68 ± (20.64 - 20.72) ms	20.65 ± (20.62 - 20.69) ms	-0.1%	✅
process.time_to_main_ms	68.25 ± (68.15 - 68.35) ms	68.06 ± (67.95 - 68.17) ms	-0.3%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.62 ± (10.62 - 10.62) MB	10.64 ± (10.63 - 10.64) MB	+0.2%	✅⬆️
runtime.dotnet.threads.count	10 ± (10 - 10)	10 ± (10 - 10)	+0.0%	✅
.NET 6 - Bailout
process.internal_duration_ms	20.57 ± (20.55 - 20.59) ms	20.52 ± (20.50 - 20.55) ms	-0.2%	✅
process.time_to_main_ms	69.00 ± (68.93 - 69.07) ms	68.98 ± (68.93 - 69.03) ms	-0.0%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.68 ± (10.68 - 10.69) MB	10.74 ± (10.73 - 10.74) MB	+0.5%	✅⬆️
runtime.dotnet.threads.count	11 ± (11 - 11)	11 ± (11 - 11)	+0.0%	✅
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms	246.25 ± (244.02 - 248.47) ms	242.75 ± (240.54 - 244.96) ms	-1.4%	✅
process.time_to_main_ms	441.37 ± (440.83 - 441.91) ms	441.07 ± (440.63 - 441.50) ms	-0.1%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	48.82 ± (48.79 - 48.86) MB	48.86 ± (48.83 - 48.89) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	28 ± (28 - 28)	28 ± (28 - 28)	+0.0%	✅⬆️
.NET 8 - Baseline
process.internal_duration_ms	18.82 ± (18.79 - 18.85) ms	18.83 ± (18.80 - 18.86) ms	+0.0%	✅⬆️
process.time_to_main_ms	67.12 ± (67.02 - 67.22) ms	67.30 ± (67.19 - 67.41) ms	+0.3%	✅⬆️
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	7.68 ± (7.67 - 7.69) MB	7.68 ± (7.67 - 7.68) MB	-0.0%	✅
runtime.dotnet.threads.count	10 ± (10 - 10)	10 ± (10 - 10)	+0.0%	✅
.NET 8 - Bailout
process.internal_duration_ms	18.94 ± (18.90 - 18.97) ms	18.82 ± (18.80 - 18.84) ms	-0.6%	✅
process.time_to_main_ms	68.40 ± (68.33 - 68.47) ms	68.33 ± (68.26 - 68.39) ms	-0.1%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	7.73 ± (7.72 - 7.74) MB	7.74 ± (7.73 - 7.76) MB	+0.2%	✅⬆️
runtime.dotnet.threads.count	11 ± (11 - 11)	11 ± (11 - 11)	+0.0%	✅
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms	179.56 ± (178.58 - 180.54) ms	179.64 ± (178.53 - 180.75) ms	+0.0%	✅⬆️
process.time_to_main_ms	426.30 ± (425.70 - 426.90) ms	427.08 ± (426.47 - 427.70) ms	+0.2%	✅⬆️
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	36.42 ± (36.39 - 36.44) MB	36.46 ± (36.42 - 36.49) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	27 ± (26 - 27)	27 ± (27 - 27)	+0.4%	✅⬆️

HttpMessageHandler

Metric	Master (Mean ± 95% CI)	Current (Mean ± 95% CI)	Change	Status
.NET Framework 4.8 - Baseline
duration	192.05 ± (191.89 - 192.65) ms	193.60 ± (193.55 - 194.44) ms	+0.8%	✅⬆️
.NET Framework 4.8 - Bailout
duration	195.22 ± (194.96 - 195.52) ms	198.72 ± (198.62 - 199.42) ms	+1.8%	✅⬆️
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration	1109.71 ± (1108.66 - 1115.37) ms	1133.34 ± (1136.18 - 1145.61) ms	+2.1%	✅⬆️
.NET Core 3.1 - Baseline
process.internal_duration_ms	187.16 ± (186.74 - 187.57) ms	195.82 ± (195.24 - 196.40) ms	+4.6%	✅⬆️
process.time_to_main_ms	80.45 ± (80.23 - 80.67) ms	84.52 ± (84.17 - 84.86) ms	+5.1%	✅⬆️
runtime.dotnet.exceptions.count	3 ± (3 - 3)	3 ± (3 - 3)	+0.0%	✅
runtime.dotnet.mem.committed	16.09 ± (16.06 - 16.11) MB	15.98 ± (15.97 - 16.00) MB	-0.6%	✅
runtime.dotnet.threads.count	20 ± (19 - 20)	20 ± (20 - 20)	+0.2%	✅⬆️
.NET Core 3.1 - Bailout
process.internal_duration_ms	186.30 ± (185.99 - 186.61) ms	191.81 ± (191.35 - 192.28) ms	+3.0%	✅⬆️
process.time_to_main_ms	81.36 ± (81.24 - 81.47) ms	83.62 ± (83.40 - 83.85) ms	+2.8%	✅⬆️
runtime.dotnet.exceptions.count	3 ± (3 - 3)	3 ± (3 - 3)	+0.0%	✅
runtime.dotnet.mem.committed	16.15 ± (16.12 - 16.17) MB	16.17 ± (16.15 - 16.19) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	21 ± (21 - 21)	21 ± (21 - 21)	+0.4%	✅⬆️
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms	427.18 ± (424.11 - 430.24) ms	420.38 ± (416.99 - 423.78) ms	-1.6%	✅
process.time_to_main_ms	473.08 ± (472.35 - 473.81) ms	482.55 ± (481.56 - 483.55) ms	+2.0%	✅⬆️
runtime.dotnet.exceptions.count	3 ± (3 - 3)	3 ± (3 - 3)	+0.0%	✅
runtime.dotnet.mem.committed	58.66 ± (58.55 - 58.76) MB	58.92 ± (58.81 - 59.03) MB	+0.5%	✅⬆️
runtime.dotnet.threads.count	29 ± (29 - 29)	30 ± (29 - 30)	+0.3%	✅⬆️
.NET 6 - Baseline
process.internal_duration_ms	191.59 ± (191.29 - 191.89) ms	195.53 ± (195.08 - 195.99) ms	+2.1%	✅⬆️
process.time_to_main_ms	69.33 ± (69.19 - 69.46) ms	70.97 ± (70.76 - 71.17) ms	+2.4%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	16.10 ± (15.96 - 16.24) MB	16.37 ± (16.35 - 16.40) MB	+1.7%	✅⬆️
runtime.dotnet.threads.count	18 ± (18 - 18)	19 ± (19 - 19)	+5.7%	✅⬆️
.NET 6 - Bailout
process.internal_duration_ms	189.95 ± (189.73 - 190.16) ms	194.00 ± (193.57 - 194.42) ms	+2.1%	✅⬆️
process.time_to_main_ms	70.16 ± (70.07 - 70.24) ms	71.67 ± (71.47 - 71.86) ms	+2.2%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	15.98 ± (15.82 - 16.14) MB	16.36 ± (16.30 - 16.41) MB	+2.4%	✅⬆️
runtime.dotnet.threads.count	19 ± (19 - 19)	20 ± (20 - 20)	+3.8%	✅⬆️
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms	449.66 ± (446.68 - 452.65) ms	456.61 ± (454.31 - 458.92) ms	+1.5%	✅⬆️
process.time_to_main_ms	444.54 ± (444.02 - 445.07) ms	449.07 ± (448.58 - 449.55) ms	+1.0%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	58.43 ± (58.31 - 58.55) MB	58.39 ± (58.28 - 58.50) MB	-0.1%	✅
runtime.dotnet.threads.count	29 ± (29 - 29)	29 ± (29 - 29)	-0.0%	✅
.NET 8 - Baseline
process.internal_duration_ms	190.42 ± (190.00 - 190.85) ms	191.68 ± (191.32 - 192.05) ms	+0.7%	✅⬆️
process.time_to_main_ms	69.07 ± (68.85 - 69.29) ms	69.51 ± (69.32 - 69.70) ms	+0.6%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	11.72 ± (11.70 - 11.75) MB	11.74 ± (11.72 - 11.77) MB	+0.2%	✅⬆️
runtime.dotnet.threads.count	18 ± (18 - 18)	18 ± (18 - 18)	-0.2%	✅
.NET 8 - Bailout
process.internal_duration_ms	188.65 ± (188.44 - 188.87) ms	192.79 ± (192.34 - 193.25) ms	+2.2%	✅⬆️
process.time_to_main_ms	69.63 ± (69.54 - 69.72) ms	71.44 ± (71.27 - 71.61) ms	+2.6%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	11.79 ± (11.74 - 11.83) MB	11.83 ± (11.81 - 11.86) MB	+0.4%	✅⬆️
runtime.dotnet.threads.count	19 ± (19 - 19)	19 ± (19 - 19)	+0.4%	✅⬆️
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms	361.45 ± (359.80 - 363.10) ms	369.36 ± (368.13 - 370.60) ms	+2.2%	✅⬆️
process.time_to_main_ms	426.78 ± (426.13 - 427.43) ms	433.50 ± (432.93 - 434.07) ms	+1.6%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	48.05 ± (48.01 - 48.09) MB	48.08 ± (48.05 - 48.12) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	29 ± (29 - 29)	29 ± (29 - 29)	+0.1%	✅⬆️

Comparison explanation

Execution-time benchmarks measure the whole time it takes to execute a program, and are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are highlighted in **red**. The following thresholds were used for comparing the execution times:

Welch test with statistical test for significance of 5%
Only results indicating a difference greater than 5% and 5 ms are considered.

Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard.

Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph).

Duration charts

FakeDbCommand (.NET Framework 4.8)

gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (68ms)  : 67, 70
    master - mean (69ms)  : 67, 70

    section Bailout
    This PR (8041) - mean (72ms)  : 71, 73
    master - mean (72ms)  : 71, 74

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (1,007ms)  : 962, 1053
    master - mean (1,025ms)  : 938, 1111

FakeDbCommand (.NET Core 3.1)

gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (106ms)  : 103, 109
    master - mean (106ms)  : 104, 109

    section Bailout
    This PR (8041) - mean (107ms)  : 106, 108
    master - mean (107ms)  : 106, 108

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (734ms)  : 673, 795
    master - mean (744ms)  : 681, 807

FakeDbCommand (.NET 6)

gantt
    title Execution time (ms) FakeDbCommand (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (94ms)  : 92, 96
    master - mean (94ms)  : 92, 95

    section Bailout
    This PR (8041) - mean (94ms)  : 93, 95
    master - mean (94ms)  : 93, 95

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (709ms)  : 673, 744
    master - mean (710ms)  : 660, 759

FakeDbCommand (.NET 8)

gantt
    title Execution time (ms) FakeDbCommand (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (92ms)  : 90, 95
    master - mean (92ms)  : 90, 94

    section Bailout
    This PR (8041) - mean (93ms)  : 92, 94
    master - mean (93ms)  : 92, 95

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (636ms)  : 620, 651
    master - mean (633ms)  : 618, 649

HttpMessageHandler (.NET Framework 4.8)

gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (194ms)  : 189, 199
    master - mean (192ms)  : 189, 196

    section Bailout
    This PR (8041) - mean (199ms)  : 195, 203
    master - mean (195ms)  : 193, 198

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (1,141ms)  : 1072, 1209
    master - mean (1,112ms)  : 1063, 1161

HttpMessageHandler (.NET Core 3.1)

gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (290ms)  : 274, 305
    master - mean (276ms)  : 270, 282

    section Bailout
    This PR (8041) - mean (284ms)  : 276, 293
    master - mean (276ms)  : 272, 280

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (937ms)  : 886, 988
    master - mean (930ms)  : 889, 971

HttpMessageHandler (.NET 6)

gantt
    title Execution time (ms) HttpMessageHandler (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (275ms)  : 266, 283
    master - mean (269ms)  : 264, 274

    section Bailout
    This PR (8041) - mean (274ms)  : 266, 283
    master - mean (268ms)  : 265, 271

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (932ms)  : 884, 981
    master - mean (920ms)  : 865, 975

HttpMessageHandler (.NET 8)

gantt
    title Execution time (ms) HttpMessageHandler (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8041) - mean (271ms)  : 266, 276
    master - mean (269ms)  : 263, 275

    section Bailout
    This PR (8041) - mean (274ms)  : 268, 280
    master - mean (268ms)  : 264, 271

    section CallTarget+Inlining+NGEN
    This PR (8041) - mean (834ms)  : 807, 860
    master - mean (820ms)  : 798, 842

## Summary of changes Avoids allocating a closure in .NET Core if we can avoid it ## Reason for change .NET Core's `ConcurrentDictionary.GetOrAdd()` method allows providing a "state" object which we can pass to the `GetOrAdd` method. Using this method avoids allocating a closure every time the method is hit, and we can pass the state using a value tuple to avoid additional allocation there ## Implementation details `#if`/`#else` to glory ## Test coverage Functionality is covered by existing tests, benchmarks show an incremental improvement over #8037 for .NET Core, as expected: | Method | Runtime | Mean | StdDev | Gen0 | Allocated | Compared to #8037 | | ------------------------------- | -------------------- | -------: | --------: | -----: | --------: | ----------------: | | StartStopWithChild_Hierarchical | .NET 6.0 | 3.746 us | 0.1128 us | 0.0114 | 3.81 KB | -0.28 KB | | StartStopWithChild_Hierarchical | .NET 8.0 | 2.759 us | 0.0374 us | 0.0114 | 3.81 KB | -0.28 KB | | StartStopWithChild_Hierarchical | .NET Core 3.1 | 4.762 us | 0.0584 us | 0.0153 | 4.04 KB | -0.28 KB | | StartStopWithChild_Hierarchical | .NET Framework 4.7.2 | 5.651 us | 0.0717 us | 0.7324 | 4.54 KB | 0.01 KB (noise) | | | | | | | | | | StartStopWithChild | .NET 6.0 | 3.607 us | 0.0508 us | 0.0153 | 4.02 KB | -0.28 KB | | StartStopWithChild | .NET 8.0 | 2.921 us | 0.0617 us | 0.0114 | 3.91 KB | -0.29 KB | | StartStopWithChild | .NET Core 3.1 | 4.922 us | 0.0407 us | 0.0153 | 4.2 KB | -0.28 KB | | StartStopWithChild | .NET Framework 4.7.2 | 6.008 us | 0.0979 us | 0.7629 | 4.69 KB | 0 | ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-915 Part of a stack working to improve OTel performance - #8036 - #8037 - #8038 - #8039 👈 - #8040 - #8041 - #8042

## Summary of changes Reduce allocation of `ActivityHandlerCommon` by removing `string` concatenation ## Reason for change The `ActivityHandlerCommon.ActivityStarted` and `ActivityStopped` methods need to store and retrieve `Activity` instances from a `ConcurrentDictionary<>`. Today they're doing that be concatenating the `Activity`'s `TraceId` and `SpanID`, or by using it's `ID`. All that concatenation causes a bunch of allocation, so instead introduce a simple `struct` to use as the key instead ## Implementation details Introduce `ActivityKey`, which is essentially `internal readonly record struct ActivityKey(string TraceId, string SpanId`, and use that for all of the dictionary lookups. Which avoids all the string concatenation allocations. ## Test coverage Added some unit tests for `ActivityKey`, by mostly covered by existing integration tests for correctness. Benchmarks show a significant improvement over [the previous results](#8036), particularly for Hierachical IDs which clearly were buggy | Method | Runtime | Mean | StdDev | Gen0 | Allocated | Compared to #8036 | | ------------------------------- | -------------------- | -------: | --------: | -----: | --------: | ----------------: | | StartStopWithChild_Hierarchical | .NET 6.0 | 4.217 us | 0.3227 us | 0.0153 | 4.09 KB | -6.38 KB | | StartStopWithChild_Hierarchical | .NET 8.0 | 3.413 us | 0.2505 us | 0.0076 | 4.09 KB | -6.39 KB | | StartStopWithChild_Hierarchical | .NET Core 3.1 | 5.676 us | 0.4636 us | 0.0153 | 4.32 KB | -6.43 KB | | StartStopWithChild_Hierarchical | .NET Framework 4.7.2 | 6.813 us | 0.4969 us | 0.7324 | 4.53 KB | -7.24 KB | | | | | | | | | | StartStopWithChild | .NET 6.0 | 4.105 us | 0.2677 us | 0.0153 | 4.3 KB | -0.57 KB | | StartStopWithChild | .NET 8.0 | 3.475 us | 0.1570 us | 0.0114 | 4.2 KB | -0.57 KB | | StartStopWithChild | .NET Core 3.1 | 5.647 us | 0.3129 us | 0.0153 | 4.48 KB | -0.57 KB | | StartStopWithChild | .NET Framework 4.7.2 | 6.842 us | 0.2992 us | 0.7629 | 4.69 KB | -0.61 KB | ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-915 Part of a stack working to improve OTel performance - #8036 - #8037 👈 - #8038 - #8039 - #8040 - #8041 - #8042

pr-commenter · 2026-01-12T15:36:46Z

Benchmarks

Benchmark execution time: 2026-01-12 19:43:16

Comparing candidate commit 1630be2 in PR branch andrew/otel/enumeration with baseline commit 370c5a6 in branch master.

Found 12 performance improvements and 1 performance regressions! Performance is the same for 157 metrics, 16 unstable metrics.

scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild net472

🟩 throughput [+14142.321op/s; +14527.919op/s] or [+21.812%; +22.406%]

scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild netcoreapp3.1

🟩 throughput [+11807.422op/s; +13104.505op/s] or [+16.230%; +18.013%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleSimpleBody net6.0

🟩 execution_time [-29.323ms; -22.755ms] or [-13.135%; -10.193%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleSimpleBody netcoreapp3.1

🟩 execution_time [-18.738ms; -12.483ms] or [-8.776%; -5.846%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody net6.0

🟩 execution_time [-17.872ms; -12.468ms] or [-8.344%; -5.821%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody netcoreapp3.1

🟩 execution_time [-16.230ms; -10.593ms] or [-7.716%; -5.037%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody net6.0

🟩 execution_time [-25.846ms; -19.674ms] or [-11.693%; -8.901%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeLegacyArgs net6.0

🟩 execution_time [-30.926ms; -30.114ms] or [-14.995%; -14.601%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces net472

🟩 execution_time [-35.995ms; -31.502ms] or [-15.935%; -13.946%]
🟩 throughput [+91.326op/s; +115.535op/s] or [+8.594%; +10.872%]

scenario:Benchmarks.Trace.Log4netBenchmark.EnrichedLog netcoreapp3.1

🟥 execution_time [+24.726ms; +29.751ms] or [+14.160%; +17.038%]

scenario:Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin netcoreapp3.1

🟩 execution_time [-16.954ms; -11.035ms] or [-8.130%; -5.292%]
🟩 throughput [+38798.079op/s; +60893.475op/s] or [+5.452%; +8.557%]

## Summary of changes Various optimizations in the `Activity` handling code to reduce allocations and execution time ## Reason for change Some properties are triksy, as they do a bunch of allocation, so we should avoid them if we can. The changes in here _look_ bigger than they are diff-wise, I've added comments to aid review. ## Implementation details - Don't call `ParentId` until we definitely need it. - This property does a bunch of allocation to generate a "valid" value, so we should avoid it if we can. This makes the conditions a bit harder to read, but delays calling `ParentId` until we're sure we don't have something better already - Avoid calling `Tracer.Instance.ActiveScope?.Span` until we know we need it (very minor optimisations but why not 🤷‍♂️) - Extract `StopActivitySlow` to a separate method, as we _shouldn't_ hit this now, so should help the JIT out with things like code size etc of the calling method (conjecture, not tested, but I think it's better from code understanding PoV too) - Simplify `ShouldIgnoreByOperationName` which also improves execution time 10x from ~30us to ~3us. ## Test coverage Functionally covered by existing tests. Benchmarks compared to #8039 show improvments. Allocations listed below, but execution time is also improved: I re-ran the numbers after making the updates, and the benchmarks are actually better: <details><summary>Benchmarks for original PR</summary> <p> | Method | Runtime | Mean | StdDev | Gen0 | Allocated | Compared to #8039 | | ------------------------------- | -------------------- | -------: | --------: | -----: | --------: | ----------------: | | StartStopWithChild_Hierarchical | .NET 6.0 | 3.410 us | 0.0658 us | 0.0153 | 3.79 KB | -0.02 KB | | StartStopWithChild_Hierarchical | .NET 8.0 | 2.582 us | 0.0443 us | 0.0114 | 3.79 KB | -0.02 KB | | StartStopWithChild_Hierarchical | .NET Core 3.1 | 4.272 us | 0.0731 us | 0.0153 | 4.02 KB | -0.02 KB | | StartStopWithChild_Hierarchical | .NET Framework 4.7.2 | 5.165 us | 0.1245 us | 0.7324 | 4.51 KB | -0.03 KB | | | | | | | | | | StartStopWithChild | .NET 6.0 | 3.312 us | 0.0266 us | 0.0153 | 3.78 KB | -0.04 KB | | StartStopWithChild | .NET 8.0 | 2.648 us | 0.0306 us | 0.0114 | 3.78 KB | -0.13 KB | | StartStopWithChild | .NET Core 3.1 | 4.344 us | 0.0555 us | 0.0076 | 3.97 KB | -0.23 KB | | StartStopWithChild | .NET Framework 4.7.2 | 5.234 us | 0.1568 us | 0.7095 | 4.39 KB | -0.30 KB | </p> </details> | Method | Runtime | Mean | StdDev | Gen0 | Allocated | Alloc Ratio | | ------------------------------- | -------------------- | -------: | --------: | -----: | --------: | ----------: | | StartStopWithChild_Hierarchical | .NET 6.0 | 3.770 us | 0.3101 us | 0.0076 | 3.58 KB | -0.23 KB | | StartStopWithChild_Hierarchical | .NET 8.0 | 3.039 us | 0.2377 us | 0.0076 | 3.58 KB | -0.23 KB | | StartStopWithChild_Hierarchical | .NET Core 3.1 | 4.490 us | 0.1135 us | 0.0076 | 3.8 KB | -0.22 KB | | StartStopWithChild_Hierarchical | .NET Framework 4.7.2 | 5.303 us | 0.2469 us | 0.6943 | 4.3 KB | -0.24 KB | | | | | | | | | | StartStopWithChild | .NET 6.0 | 3.386 us | 0.0971 us | 0.0114 | 3.59 KB | -0.43 KB | | StartStopWithChild | .NET 8.0 | 2.661 us | 0.0218 us | 0.0114 | 3.59 KB | -0.32 KB | | StartStopWithChild | .NET Core 3.1 | 4.540 us | 0.1625 us | 0.0076 | 3.78 KB | -0.42 KB | | StartStopWithChild | .NET Framework 4.7.2 | 5.563 us | 0.1946 us | 0.6790 | 4.2 KB | -0.49 KB | ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-915 Part of a stack working to improve OTel performance - #8036 - #8037 - #8038 - #8039 - #8040 👈 - #8041 - #8042

TODO: - Add unit tests - Add tests for handling of fallback path, particularly with "old" activity types - Benchmark across all different TFMs - Expose more widely? - Use for activity links and events

- Explicitly checks we have the correct type on every execution - Does an allocating-enumeration if we have the wrong type - Encapsulate the enumeration

…ator.cs Co-authored-by: Lucas Pimentel <lucas.pimentel@datadoghq.com>

…8042) ## Summary of changes Improve performance around the "population" of tags from an `Activity` into a `Span` ## Reason for change Currently we do a _lot_ of allocation in the `OtlpHelpers.AgentConvertSpan` method. The `OpenTelemetryTags` object also has a lot of properties on it that we never set, and are only used for _reading_ tags in the `OperationMapper`, even though many may never even be read. This increases the size of the tags object. This PR aims to do various optimizations around the "close activity" paths: - Reduce the size of the `OpenTelemetryTags` object by removing properties only used by `OperationMapper` - Add properties to `OpenTelemetryTags` for values that we explictly set in `OtlpHelpers.AgentConvertSpan` ## Implementation details - Currently we're always creating the `OpenTelemetryTags`, even though we _may_ throw it away if the activity is ignored, so that's an easy win. - I think we can assume that the tags object passed to `AgentConvertSpan` is only ever `OpenTelemetryTags` based on the call sites, so we can interact with the tags object directly where posisble. - "Simplify" some of the code paths by avoiding `span.SetTag` and favouring `tags.SetTag` when we know it's not a "special" tag. - Inline a few method calls in places where they will often not be called, at the expense of some clarity - Refactor `OperationMapper` to use the `GetTag()` API, and cache the values at various points. The resulting code is uglier, but overall means we reduce ~100 bytes off every span, so I think it's worth it ## Test coverage Functionality is covered by existing, this is just a refactoring, and there's good tests for `OperationMapper` currently. Benchmarks vs #8041 show a nice allocation improvement, at the expense of slower execution (this was local though, so not 100% on that, will see what the CI results show). If there is a significant slow down, I'll try to isolate it, but I think the allocation improvments are probably worth it either way | Method | Runtime | Mean | StdDev | Gen0 | Allocated | Compared to #8041 | | ------------------------------- | -------------------- | -------: | --------: | -----: | --------: | ----------------: | | StartStopWithChild_Hierarchical | .NET 6.0 | 4.438 us | 0.7347 us | 0.0076 | 3.2 KB | -0.40 KB | | StartStopWithChild_Hierarchical | .NET 8.0 | 3.216 us | 0.4260 us | 0.0076 | 3.2 KB | -0.40 KB | | StartStopWithChild_Hierarchical | .NET Core 3.1 | 5.293 us | 0.8316 us | 0.0076 | 3.42 KB | -0.41 KB | | StartStopWithChild_Hierarchical | .NET Framework 4.7.2 | 5.735 us | 0.5592 us | 0.6332 | 3.92 KB | -0.41 KB | | | | | | | | | | StartStopWithChild | .NET 6.0 | 3.848 us | 0.5325 us | 0.0076 | 3.19 KB | -0.40 KB | | StartStopWithChild | .NET 8.0 | 3.080 us | 0.2698 us | 0.0076 | 3.19 KB | -0.40 KB | | StartStopWithChild | .NET Core 3.1 | 5.094 us | 0.4982 us | 0.0076 | 3.38 KB | -0.40 KB | | StartStopWithChild | .NET Framework 4.7.2 | 6.172 us | 0.5948 us | 0.6104 | 3.79 KB | -0.41 KB | ## Other details Added a couple of extra tests that were missing from the previous PR in the stack too https://datadoghq.atlassian.net/browse/LANGPLAT-915 Part of a stack working to improve OTel performance - #8036 - #8037 - #8038 - #8039 - #8040 - #8041 - #8042 👈

…#8058) ## Summary of changes Don't use the `DynamicMethod` approach in .NET 10 ## Reason for change In #8041 we added allocation-free enumeration of tags objects by building a `DynamicMethod` that calls the `struct` method to avoid boxing. I benchmarked it on a bunch of TFMs, but missed .NET 10. However, .NET 10 enumeration is _already_ allocation free, so the `DynamicMethod` actually hurts performance (presumably primarily because it messes with other inlining and stack allocation improvements the JIT can do), so we _shouldn't_ use the `DynamicMethod` approach in .NET 10 😅 ## Implementation details - Just do a "normal" enumeration of the tags if it's .NET 10 - Add .NET 10 to the benchmark project TFMs ## Test coverage Did a quick benchmark comparing naive enumeration of the tag objects of a duck typed activity with and without the dynamic method approach. In general, the results are better for `DynamicMethod` in all these TFMs _except_ .NET 10 (I tested .NET 8/9 previously and confirmed `DynamicMEthod` is better there too) | Method | Runtime | Mean | Error | StdDev | Median | Allocated | | -------------------------- | ------------------ | -------: | -------: | -------: | -------: | --------: | | EnumerateTags | .NET 10.0 | 189.9 ns | 6.94 ns | 20.46 ns | 182.6 ns | 592 B | | EnumerateTagsDynamicMethod | .NET 10.0 | 205.6 ns | 4.14 ns | 8.83 ns | 205.1 ns | 592 B | | | | | | | | | | EnumerateTags | .NET 6.0 | 366.1 ns | 9.49 ns | 27.54 ns | 361.0 ns | 624 B | | EnumerateTagsDynamicMethod | .NET 6.0 | 307.9 ns | 6.37 ns | 18.29 ns | 299.4 ns | 592 B | | | | | | | | | | EnumerateTags | .NET Core 3.1 | 501.0 ns | 12.15 ns | 35.64 ns | 494.2 ns | 672 B | | EnumerateTagsDynamicMethod | .NET Core 3.1 | 441.9 ns | 8.83 ns | 25.19 ns | 436.7 ns | 640 B | | | | | | | | | | EnumerateTags | .NET Framework 4.8 | 536.9 ns | 10.52 ns | 14.05 ns | 534.7 ns | 746 B | | EnumerateTagsDynamicMethod | .NET Framework 4.8 | 542.4 ns | 13.83 ns | 40.33 ns | 534.9 ns | 714 B | <details><summary>Benchmark additions in `ActivityBenchmark</summary> <p> ```csharp private AllocationFreeEnumerator<IEnumerable<KeyValuePair<string, object?>>, KeyValuePair<string, object?>, long>.AllocationFreeForEachDelegate _enumerator; [GlobalSetup] public void GlobalSetup() { // ... using var activity = CreateActivity(); _enumerator = AllocationFreeEnumerator<IEnumerable<KeyValuePair<string, object?>>, KeyValuePair<string, object?>, long> .BuildAllocationFreeForEachDelegate(activity.DuckCast<IActivity6>().TagObjects.GetType()); } [Benchmark] public long EnumerateTags() { using var parent = CreateActivity(); var parentMock = parent.DuckCast<IActivity6>(); long count = 0; foreach (var pair in parentMock.TagObjects) { count++; } return count; } [Benchmark] public long EnumerateTagsDynamicMethod() { using var parent = CreateActivity(); var parentMock = parent.DuckCast<IActivity6>(); long count = 0; _enumerator( parentMock.TagObjects, ref count, static (ref state, i) => { state++; return true; }); return count; } ``` </p> </details>

andrewlock added type:performance Performance, speed, latency, resource usage (CPU, memory) area:opentelemetry OpenTelemetry support labels Jan 8, 2026

This was referenced Jan 8, 2026

Improve OpenTelemetryTags population to reduce allocation and work #8042

Merged

Various optimizations for Activity handling #8040

Merged

andrewlock added the type:refactor label Jan 8, 2026

This was referenced Jan 8, 2026

Avoid allocating a closure for ActivityMappingById.GetOrAdd #8039

Merged

Fix nullable annotations on Activity duck types #8038

Merged

Introduce ActivityKey to remove string concatenation #8037

Merged

andrewlock marked this pull request as ready for review January 8, 2026 16:26

andrewlock requested review from a team as code owners January 8, 2026 16:26

andrewlock requested review from anna-git and removed request for a team January 8, 2026 16:26

This comment has been minimized.

Sign in to view

bouwkast reviewed Jan 8, 2026

View reviewed changes

andrewlock mentioned this pull request Jan 9, 2026

Update Activity benchmarks for stability #8036

Merged

andrewlock force-pushed the andrew/otel/enumeration branch from 0719f68 to 05a7274 Compare January 9, 2026 11:29

andrewlock requested review from a team as code owners January 9, 2026 11:29

andrewlock force-pushed the andrew/otel/ParentId branch from c54293a to 052d4a9 Compare January 9, 2026 11:30

andrewlock force-pushed the andrew/otel/enumeration branch from 05a7274 to 7d277c0 Compare January 9, 2026 13:53

andrewlock force-pushed the andrew/otel/ParentId branch from 052d4a9 to 2e9e4cf Compare January 9, 2026 13:53

andrewlock force-pushed the andrew/otel/ParentId branch from 2e9e4cf to ff96a9a Compare January 9, 2026 17:08

andrewlock force-pushed the andrew/otel/enumeration branch from 7d277c0 to 6d3f6ca Compare January 9, 2026 17:47

tonyredondo approved these changes Jan 9, 2026

View reviewed changes

lucaspimentel reviewed Jan 9, 2026

View reviewed changes

tracer/src/Datadog.Trace/Activity/Helpers/AllocationFreeEnumerator.cs Outdated Show resolved Hide resolved

lucaspimentel approved these changes Jan 9, 2026

View reviewed changes

andrewlock force-pushed the andrew/otel/enumeration branch from 6d3f6ca to a3be7e1 Compare January 10, 2026 12:57

andrewlock force-pushed the andrew/otel/ParentId branch from ff96a9a to 81a3391 Compare January 10, 2026 12:57

andrewlock force-pushed the andrew/otel/ParentId branch 2 times, most recently from 0996918 to 982d0dc Compare January 12, 2026 14:54

andrewlock force-pushed the andrew/otel/enumeration branch from a3be7e1 to b6392a3 Compare January 12, 2026 14:56

Base automatically changed from andrew/otel/ParentId to master January 12, 2026 18:58

andrewlock and others added 7 commits January 12, 2026 18:59

Add allocation-free activity tags enumeration helpers.

08856ea

TODO: - Add unit tests - Add tests for handling of fallback path, particularly with "old" activity types - Benchmark across all different TFMs - Expose more widely? - Use for activity links and events

Avoid allocating and iterating links and activities if we don't have any

163f938

Add unit tests

f81860a

Add debug-only guards for type

51a5a35

Add comment to state

29c9f85

Make ActivityEnumeration helper safer

70b8951

- Explicitly checks we have the correct type on every execution - Does an allocating-enumeration if we have the wrong type - Encapsulate the enumeration

Update tracer/src/Datadog.Trace/Activity/Helpers/AllocationFreeEnumer…

1630be2

…ator.cs Co-authored-by: Lucas Pimentel <lucas.pimentel@datadoghq.com>

andrewlock force-pushed the andrew/otel/enumeration branch from 876d552 to 1630be2 Compare January 12, 2026 19:01

andrewlock merged commit de2b9cd into master Jan 13, 2026
151 checks passed

andrewlock deleted the andrew/otel/enumeration branch January 13, 2026 08:56

github-actions bot added this to the vNext-v3 milestone Jan 13, 2026

andrewlock mentioned this pull request Jan 14, 2026

Don't do DynamicMethod based allocation-free enumeration on .NET 10 #8058

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Switch to allocation-free enumeration of `Activity` objects#8041