Remove unnecessary use of duck typing in HTTP integrations#8275
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b8972af334
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
b8972af to
cb0d3e6
Compare
BenchmarksBenchmark execution time: 2026-03-10 14:29:57 Comparing candidate commit 6930a63 in PR branch Found 13 performance improvements and 5 performance regressions! Performance is the same for 161 metrics, 13 unstable metrics. scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild net472
scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild netcoreapp3.1
scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleSimpleBody netcoreapp3.1
scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest netcoreapp3.1
scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice netcoreapp3.1
scenario:Benchmarks.Trace.CharSliceBenchmark.OriginalCharSlice net6.0
scenario:Benchmarks.Trace.DbCommandBenchmark.ExecuteNonQuery netcoreapp3.1
scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearch net472
scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearchAsync net472
scenario:Benchmarks.Trace.HttpClientBenchmark.SendAsync net6.0
scenario:Benchmarks.Trace.Log4netBenchmark.EnrichedLog netcoreapp3.1
scenario:Benchmarks.Trace.NLogBenchmark.EnrichedLog net6.0
scenario:Benchmarks.Trace.RedisBenchmark.SendReceive net472
scenario:Benchmarks.Trace.SerilogBenchmark.EnrichedLog net472
scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore netcoreapp3.1
scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan netcoreapp3.1
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8275) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-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:
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 chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8275) - mean (77ms) : 74, 79
master - mean (75ms) : 73, 77
section Bailout
This PR (8275) - mean (82ms) : 80, 84
master - mean (79ms) : 77, 81
section CallTarget+Inlining+NGEN
This PR (8275) - mean (1,105ms) : 1072, 1138
master - mean (1,086ms) : 1041, 1132
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 (8275) - mean (121ms) : 117, 125
master - mean (116ms) : 113, 119
section Bailout
This PR (8275) - mean (121ms) : 118, 124
master - mean (117ms) : 114, 121
section CallTarget+Inlining+NGEN
This PR (8275) - mean (775ms) : 750, 799
master - mean (776ms) : 715, 837
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8275) - mean (109ms) : 106, 113
master - mean (104ms) : 100, 108
section Bailout
This PR (8275) - mean (109ms) : 106, 111
master - mean (106ms) : 103, 108
section CallTarget+Inlining+NGEN
This PR (8275) - mean (746ms) : 702, 790
master - mean (765ms) : 695, 835
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8275) - mean (106ms) : 102, 110
master - mean (103ms) : 99, 106
section Bailout
This PR (8275) - mean (108ms) : 105, 111
master - mean (104ms) : 102, 106
section CallTarget+Inlining+NGEN
This PR (8275) - mean (671ms) : 647, 695
master - mean (681ms) : 655, 707
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 (8275) - mean (198ms) : 193, 203
master - mean (193ms) : 189, 198
section Bailout
This PR (8275) - mean (200ms) : 197, 204
master - mean (197ms) : 195, 199
section CallTarget+Inlining+NGEN
This PR (8275) - mean (1,169ms) : 1107, 1231
master - mean (1,164ms) : 1092, 1237
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 (8275) - mean (281ms) : 276, 286
master - mean (278ms) : 273, 284
section Bailout
This PR (8275) - mean (281ms) : 277, 286
master - mean (280ms) : 274, 287
section CallTarget+Inlining+NGEN
This PR (8275) - mean (911ms) : 882, 939
master - mean (948ms) : 906, 989
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8275) - mean (274ms) : 268, 281
master - mean (273ms) : 267, 279
section Bailout
This PR (8275) - mean (275ms) : 269, 281
master - mean (275ms) : 266, 284
section CallTarget+Inlining+NGEN
This PR (8275) - mean (916ms) : 886, 947
master - mean (936ms) : 903, 970
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8275) - mean (275ms) : 269, 280
master - mean (271ms) : 264, 277
section Bailout
This PR (8275) - mean (273ms) : 269, 277
master - mean (272ms) : 268, 276
section CallTarget+Inlining+NGEN
This PR (8275) - mean (829ms) : 805, 853
master - mean (835ms) : 815, 855
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
20de0d5 to
3174d5a
Compare
Summary of changes
Removes unnecessary use of duck typing in HTTP integrations
Reason for change
We're currently always using duck typing in the various HTTP integrations, but these types are always unconditionally available in .NET Core (and we already reference those assemblies), so the duck typing is an unnecessary layer that will reduce performance for no benefit.
Implementation details
#ifour way to glory on the HTTP (and one of the gRPC) integrations. If we're on .NET Core, these types are available, so we just use themTest coverage
Just a refactoring, so all the existing tests should cover this change.
Hopefully we'll see some tiny movement on the benchmarks, but I don't hold out a huge amount of hope for that. Either way, I think this change can only be an improvement, so is worth it.
Other details
Deleted the excessive comments on our integrations, seeing as they're just noise and don't tell us much (we exclude them by default on new integrations now)
One very interesting point - we can't reference the "well known types" directly in the integrations, because this causes failures when there are multiple Assembly Load Contexts. This is kinda surprising, but something to bear in mind, and something we potentially need to look into elsewhere too...